** Description changed: + [Impact] + + * capability caching by libvirt is required for efficiency, but + often stumbles over changes it misses to pick up and refresh + + * This backports several fixes to catch more of such situations + and refresh the caches in those cases + - AMD SEV changed + - s390x protvirt changed + - CPU changed + + * Backporting these changes + + [Test Case] + + * For AMS SEV and s390x protvirt you'd need the respective HW and + environments. Maybe IBM can test the latter then. + - For nested we can test it thou + 1. create a guest with host-model type + 2. install libvirt in the guest + 3. run "virsh capabilities" and save it to a file + 4. shut down guest + 5. edit the guest and take away some cpu features + 6. start guest again and run "virsh capabilities" again + It will still report these features as present (wrong) + + With the fix at #6 it will realize the CPU has changed and refresh the + capabilities cache. + + [Regression Potential] + + * This increases the amount of capability refreshes, the regression that + comes to mind is that if this contains false-positives it might trigger + too often and therefore slow down operations on systems where this + happens. + Functionally that would be no breakage, even not caching at all works + fine, but a performance issue. The added tests seem fine thou as a cpu + attribute has to change which isn't a high frequency event. + + [Other Info] + + * n/a + + --- + Stale libvirt cache leads to VM startup failures - - Contact Information = Viktor Mihajlovski <mihaj...@de.ibm.com> - + + Contact Information = Viktor Mihajlovski <mihaj...@de.ibm.com> + ---Additional Hardware Info--- - Z15 with IBM Secute Execution + Z15 with IBM Secute Execution - ---uname output--- Linux linux02 5.4.0-21-generic #25-Ubuntu SMP Sat Mar 28 13:10:00 UTC 2020 s390x s390x s390x GNU/Linux - - Machine Type = 8562 (IBM Z15) - + + Machine Type = 8562 (IBM Z15) + ---Debugger--- A debugger is not configured - + ---Steps to Reproduce--- 1. Install Ubuntu 20.04 in the LPAR 2. Modify the host kernel command line in /etc/zipl.conf to include prot_virt=1, run zipl and reboot. 3. Define at least one KVM guest with host CPU model and start and stop it 4. Define a secure KVM guest using the host CPU model and start and stop it. 5. Change back the host kernel command line, re-run zipl, reboot. 6. Try to start the first KVM guest, which fails with a message like: - error: internal error: qemu unexpectedly closed the monitor: 2020-04-23T13:55:30.889152Z qemu-system-s390x: Some features requested in the CPU model are not available in the configuration: unpack + error: internal error: qemu unexpectedly closed the monitor: 2020-04-23T13:55:30.889152Z qemu-system-s390x: Some features requested in the CPU model are not available in the configuration: unpack The reason for that is that libvirt caches the domaincapabilities reported during the first boot and doesn't update them after the reboot in step 5 even though changing the prot_virt= in the command line changes the CPU features as reported by domcapabilities. So even though the guest may not require the unpack feature, libvirt constructs a CPU model which can't be satisfied on this configuration. The issue also occurs the other way around, going from prot_virt=0 to prot_virt=1, in which case the guest will fail to boot as it requires the unpack feature. Manually removing the content of /var/cache/libvirt/qemu/capabilities/ will force libvirt to refresh it's capabilities cache and temporarily resolve the situation.
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1874647 Title: [Ubuntu 20.04] Stale libvirt cache leads to VM startup failures To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1874647/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
