Bug 1479448 - vm boot very slowly running with vhost-user when cpuset is configured
vm boot very slowly running with vhost-user when cpuset is configured
Status: CLOSED WORKSFORME
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm-rhev (Show other bugs)
7.4-Alt
aarch64 Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Wei Huang
Virtualization Bugs
: OtherQA
Depends On:
Blocks: 1174832
  Show dependency treegraph
 
Reported: 2017-08-08 10:52 EDT by Wei Huang
Modified: 2017-09-25 09:23 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-09-25 09:23:31 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Wei Huang 2017-08-08 10:52:32 EDT
=== Description ===
We saw VM booting very slowly with the following two settings in the guest config file:
  1. cpuset
  2. vhost-user

It seems this problem happened on 4.11.0-17.el7a.aarch64 kernel, but not with kernel 4.11.0-10.el7a.aarch64. We also found that, at least on arm1 (a Gigabyte machine owned by network team) machine, lower index of physical cores (e.g. 6, 7, 8, 9) will cause the problem. But a larger index numbers allow VM to boot successfully.

==== Setting Details ====
1. cpuset
  <vcpu placement='static' cpuset='6-9'>4</vcpu>
  <cputune>
    <vcpupin vcpu='0' cpuset='6'/>
    <vcpupin vcpu='1' cpuset='7'/>
    <vcpupin vcpu='2' cpuset='8'/>
    <vcpupin vcpu='3' cpuset='9'/>
  </cputune>
2. vhost user
    <interface type='vhostuser'>
      <mac address='00:be:ef:00:ba:be'/>
      <source type='unix' path='/usr/local/var/run/openvswitch/vhost1' mode='client'/>
      <model type='virtio'/>
      <driver queues='4'>
        <host mrg_rxbuf='off'/>
      </driver>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/>
    </interface>
Comment 2 Wei Huang 2017-09-22 23:34:29 EDT
We haven't seen this problem after a clean installation on failed machines. I am cc'ing the original reporter. If he can confirm that it has be resolved, we can close this BZ.
Comment 3 Bill Townsend 2017-09-25 09:23:31 EDT
Yes, this has cleared up and I have not seen it again.

Note You need to log in before you can comment on or make changes to this bug.