The case with the module parameter in SEV needs a fix similar to
https://libvirt.org/git/?p=libvirt.git;a=commit;h=b183a75319b90d0af5512be513743e1eab950612
as it can be re-loaded at any time.
Essentially the checks in virQEMUCapsLoadCache check qemu/kernel version and
many other things.
They also check microcode version ...
I think the decision there can be two ways, either "on any reboot we need to
refresh caps" which makes the code small but probably also wastes quite some
refreshes that were not needed.
Or it could along all the versions that it checks also keep a full string of
/proc/cmdline and compare it. If changed it needs to be refreshed.
I agree to Frank that this should be reported upstream.
No matter if you or I write a fix, it needs to go upstream then - so a bug
tracker there can't hurt.
OTOH you can as well start right away with a RFC patch there if you have
something prepared already - there is no "strict need" for an upstream bug,
only if you hope someone there will fix it for you.
Since workarounds are available the prio is medium IMHO, eager to see
what upstream thinks.
P.S. Even if you have no patch, it would be great if you (as the
affected) would kick off the discussion upstream. Please provide a link
here to the mailing list entry.
** Package changed: linux (Ubuntu) => libvirt (Ubuntu)
** Changed in: libvirt (Ubuntu)
Status: New => Triaged
** Changed in: libvirt (Ubuntu)
Importance: Undecided => Medium
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1874647
Title:
[Ubuntu 20.04] Stale libvirt cache leads to VM startup failures
Status in Ubuntu on IBM z Systems:
Incomplete
Status in libvirt package in Ubuntu:
Triaged
Bug description:
Stale libvirt cache leads to VM startup failures
Contact Information = Viktor Mihajlovski <[email protected]>
---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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1874647/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : [email protected]
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
