group.of.nepali.translators team mailing list archive

[Launchpad Bug Tracker <1830268@xxxxxxxxxxxxxxxxxx>]

This bug was fixed in the package libvirt - 4.6.0-2ubuntu3.6

---------------
libvirt (4.6.0-2ubuntu3.6) cosmic; urgency=medium

  * d/p/ubuntu/lp-1830268-refresh-capabilities-on-KVM-nesting.patch: fix
    consideration of VMX flag (LP: #1830268)

 -- Christian Ehrhardt <christian.ehrhardt@xxxxxxxxxxxxx>  Tue, 28 May
2019 07:59:48 +0200

** Changed in: libvirt (Ubuntu Cosmic)
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1830268

Title:
  Use changed nested VMX attribute as trigger to refresh libvirt
  capability cache

Status in libvirt package in Ubuntu:
  Fix Released
Status in libvirt source package in Xenial:
  Invalid
Status in libvirt source package in Bionic:
  In Progress
Status in libvirt source package in Cosmic:
  Fix Released

Bug description:
  [impact]

  libvirt caches the 'nested vmx' capability of the host and does not
  update that even if the host's capability to handle nested vmx
  changes.  Having this domcapability missing means no guests are able
  to start any nested, kvm-accelerated, guests.  Additionally, since
  openstack live migration requires matching cpu features, this makes
  migrating guests that do have vmx enabled impossible to hosts where
  libvirt thinks nested vmx is disabled.

  Once the kernel module (kvm_intel) is reloaded with 'nested' enabled,
  libvirt does not update its domcapabilities cache, even over a
  libvirtd restart, or even over an entire system reboot.  Only certain
  conditions cause libvirt to update its capabilities cache (possibly
  libvirt upgrade, or qemu upgrade, or kernel upgrade...I haven't
  verified any of those yet)

  libvirt creates caches for its domcapabilities at /var/cache/libvirt/qemu/capabilities/.
  removing the cache xml files there and restarting libvirtd will cause the caches to be recreated with the correct current values.

  The fix backports the upstream fix:
  https://libvirt.org/git/?p=libvirt.git;a=commit;h=b183a753
  Which makes it always check the current vs the last stored attribute.

  [test case]

  check the kvm_intel module nested parameter:
  $ cat /sys/module/kvm_intel/parameters/nested
  Y

  it can be Y or N.  make sure libvirt agrees with the current setting:
  $ virsh domcapabilities | grep vmx
        <feature policy='require' name='vmx'/>

  if 'nested' is Y, domcapabilities should include a vmx feature line;
  if 'nested' is N, it should have no output (i.e. vmx not supported in
  guests).

  Then, change the kernel nested setting, and re-check domcapabilities.
  Restarting libvirtd doesn't update the cache, and even rebooting the
  entire system doesn't update the cache.

  $ virsh domcapabilities | grep vmx
  $ cat /sys/module/kvm_intel/parameters/nested
  N
  $ sudo rmmod kvm_intel
  $ sudo modprobe kvm_intel nested=1
  $ cat /sys/module/kvm_intel/parameters/nested
  Y
  $ virsh domcapabilities | grep vmx
  $ sudo systemctl restart libvirtd
  $ virsh domcapabilities | grep vmx
  $

  Not only should it work, but further configurung libvirt debug [1] the fix should leave a message like this when triggering:
    VIR_DEBUG("Outdated capabilities for '%s': kvm kernel nested "
              "value changed from %d",)

  Test #2:
  - restart libvirtd
  - call `virsh domcapabilities`
  - repeat the above
  - this should later on use the cache (faster)
  - If it always regenerates the cache (see spawned qemu's and new file
    dates) the detection is wrong

  Test #3:
  - some arches (e.g. s390x) don't have this attribute, check on one of those how their behavior changes.

  [regression potential]

  This will make libvirt refresh the capability cache more often. This is a quite expensive tasks (depending on the number of qemu's installed which can be anything from none to all arch emulators and the kvm based ones ~10. Those will be forked and probed again. The new code now adds a rather safe detection as the nested attribute would usually only change on a reboot or a module reload. So it should be rather safe. The one real regression would be if the detection would be wrong and always trigger.
  I added Test #2 above to check for that.

  [other info]

  related RH bugs, though no changes appear to have resulted from either:
  https://bugzilla.redhat.com/show_bug.cgi?id=1474874
  https://bugzilla.redhat.com/show_bug.cgi?id=1650950

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1830268/+subscriptions