Some details from testing that make it even less severe ...
Note: since this was never in any Host defined any required setting would have
triggered a pre-check like:
error: the CPU is incompatible with host CPU: Host CPU does not provide
required features: ospke
But if set to optional:
<cpu match="exact">
<model>core2duo</model>
<feature policy='optional' name='osxsave'/>
<feature policy='optional' name='ospke'/>
</cpu>
Then you'd hit:
error: Failed to start domain disco-osxsave
error: internal error: process exited while connecting to monitor:
2019-04-25T12:12:01.698646Z qemu-system-x86_64: can't apply global
core2duo-x86_64-cpu.osxsave=off: Property '.osxsave' not found
Commandline:
-cpu core2duo,osxsave=off,ospke=off
With the fix in place the above becomes:
-cpu core2duo
and works again.
** Description changed:
## Bug ##
There are conditions where old qemu/libvirt created guests with the
osxsafe or ospke cpu feature:
<feature policy='require' name='osxsave'/>
<feature policy='require' name='ospke'/>
That feature was removed in recent qemu, this triggers issues starting
some old guests definitions using it after upgrade.
qemu-system-x86_64: can't apply global Broadwell-noTSX-x86_64-
cpu.osxsave=on: Property '.osxsave' not found
Same bug in Fedora (incomplete) [5] for being non reproducible -
probably didn't see the new virt-install avoiding (but not fixing) it.
## What happened ##
Both commandline arg drops "osxsave" / "ospke" were effective no-ops as
it was - quote: "never configurable: KVM never returned OSXSAVE on
GET_SUPPORTED_CPUID". See removal commits [1][2].
Discussions went on if this should be warnings instead of errors for a
while (the deprecation discussion is ongoing anyway). But for now we are
in the situation that calling qemu with those features makes it fail to
start. I'd not want to derive from upstream qemu and the discussion on
depreceation - as mentioned - is a longer one that won't resolve too
soon - a.k.a we can't wait on that.
The discussion at [3] reached no conclusion and was forgotten. I checked
with Jiri and there was no follow on.
But since specifying the features never meant anything to qemu we should at
least consider libvirt to learn about that and just not specify the flags.
If there is a good place for a warning we might emit one if required was set,
but this is not strictly required at first.
## when does it trigger => severity ##
Comment 14 [4] adds more details, we checked usage through virsh,
python-livbirt (uvtool, multipass, openstack) and virt-install. We only found
two cases in virt-install either:
- created the guest in the past --cpu=host-model
This guest will fail to start on upgrade
- pre virt-install 2.0 (not a Ubuntu combo) it would also break with
e.g. virt-install 1.5 and qemu 3.1 with --cpu=host-copy
=> Both options were not even documented anymore back n Xenial, but they are
kept for compatibility.
Overall - unless we missed a more important use case - this is ugly but not
show-stopping in prio.
+ To further enforce this not being a common case, if you'd have set
+ required you'd have got the following all along:
+
+ error: the CPU is incompatible with host CPU:
+ Host CPU does not provide required features: ospke
+
+ This is due to the features rarely (never?) exists in the host.
+ But if set to off or optional (which becomes off if the host doesn't have it)
then you'd have seen the new issue.
+
Obviously it also triggers if:
- - libvirt XML with added <feature policy='require' name='osxsave'/>
+ - libvirt XML with added <feature policy='optional' name='osxsave'/>
- virt-install with --cpu ...,+osxsave / ospke
## Workaround until resolved ##
Per the analysis above it hopefully should only affect a very low number
of people with very old virtual machines anyway, but if you are affected
you want a way out and that is fair.
For now just remove that features:
$ virsh edit <guestname>
# remove lines like these
- <feature policy='require' name='osxsave'/>
- <feature policy='require' name='ospke'/>
+ <feature policy='optional' name='osxsave'/>
+ <feature policy='optional' name='ospke'/>
Now your guest will start again.
---
[1]:
https://git.qemu.org/?p=qemu.git;a=commit;h=f1a23522b03a569f13aad49294bb4c4b1a9500c7
[2]:
https://git.qemu.org/?p=qemu.git;a=commit;h=9ccb9784b57804f5c74434ad6ccb66650a015ffc
[3]: https://www.mail-archive.com/[email protected]/msg561877.html
[4]:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1825195/comments/14
[5]: https://bugzilla.redhat.com/show_bug.cgi?id=1644848
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1825195
Title:
qemu dropped osxsave/ospke feature triggering upgrade issues
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1825195/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
