Comment 0 for bug 1874647

Stale libvirt cache leads to VM startup failures

Contact Information = Viktor Mihajlovski <email address hidden>

---Additional Hardware Info---
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)

---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

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.