| 2019-04-17 14:33:32 |
Christian Ehrhardt |
bug |
|
|
added bug |
| 2019-04-17 14:33:41 |
Christian Ehrhardt |
bug task added |
|
qemu (Ubuntu) |
|
| 2019-04-17 14:36:05 |
Christian Ehrhardt |
description |
There seem to be conditions where old qemu/libvirt created guests with the osxsafe feature
<model fallback='allow'>Broadwell-noTSX</model>
<vendor>Intel</vendor>
...
<feature policy='require' name='osxsave'/>
That feature was now removed in recent qemu.
=> https://bugzilla.redhat.com/show_bug.cgi?id=1644848
But its lack might cause issues starting some old guests using it after upgrade.
qemu-system-x86_64: can't apply global Broadwell-noTSX-x86_64-cpu.osxsave=on: Property '.osxsave' not found
I'd want to analyze omre of the background, why we have it in our IBRS type (still it seems) and if we can make modifications to make the transition more smooth. |
There seem to be conditions where old qemu/libvirt created guests with the osxsafe feature
<model fallback='allow'>Broadwell-noTSX</model>
<vendor>Intel</vendor>
...
<feature policy='require' name='osxsave'/>
That feature was now removed in recent qemu.
=> https://git.qemu.org/?p=qemu.git;a=commit;h=f1a23522
But its lack might cause issues starting some old guests 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:
=> https://bugzilla.redhat.com/show_bug.cgi?id=1644848
I'd want to analyze omre of the background, why we have it in our IBRS type (still it seems) and if we can make modifications to make the transition more smooth. |
|
| 2019-04-17 14:36:18 |
Christian Ehrhardt |
bug watch added |
|
https://bugzilla.redhat.com/show_bug.cgi?id=1644848 |
|
| 2019-04-17 14:36:18 |
Christian Ehrhardt |
bug task added |
|
qemu (Fedora) |
|
| 2019-04-17 15:22:35 |
Bug Watch Updater |
qemu (Fedora): status |
Unknown |
Won't Fix |
|
| 2019-04-17 15:22:35 |
Bug Watch Updater |
qemu (Fedora): importance |
Unknown |
Undecided |
|
| 2019-04-18 09:32:50 |
Christian Ehrhardt |
description |
There seem to be conditions where old qemu/libvirt created guests with the osxsafe feature
<model fallback='allow'>Broadwell-noTSX</model>
<vendor>Intel</vendor>
...
<feature policy='require' name='osxsave'/>
That feature was now removed in recent qemu.
=> https://git.qemu.org/?p=qemu.git;a=commit;h=f1a23522
But its lack might cause issues starting some old guests 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:
=> https://bugzilla.redhat.com/show_bug.cgi?id=1644848
I'd want to analyze omre of the background, why we have it in our IBRS type (still it seems) and if we can make modifications to make the transition more smooth. |
There seem to be conditions where old qemu/libvirt created guests with the osxsafe feature
<model fallback='allow'>Broadwell-noTSX</model>
<vendor>Intel</vendor>
...
<feature policy='require' name='osxsave'/>
That feature was now removed in recent qemu.
=> https://git.qemu.org/?p=qemu.git;a=commit;h=f1a23522
But its lack might cause issues starting some old guests 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:
=> https://bugzilla.redhat.com/show_bug.cgi?id=1644848
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.
[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/qemu-devel@nongnu.org/msg561877.html |
|
| 2019-04-18 09:34:11 |
Christian Ehrhardt |
bug |
|
|
added subscriber James Page |
| 2019-04-18 09:34:18 |
Christian Ehrhardt |
bug |
|
|
added subscriber Corey Bryant |
| 2019-04-18 09:36:07 |
Christian Ehrhardt |
description |
There seem to be conditions where old qemu/libvirt created guests with the osxsafe feature
<model fallback='allow'>Broadwell-noTSX</model>
<vendor>Intel</vendor>
...
<feature policy='require' name='osxsave'/>
That feature was now removed in recent qemu.
=> https://git.qemu.org/?p=qemu.git;a=commit;h=f1a23522
But its lack might cause issues starting some old guests 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:
=> https://bugzilla.redhat.com/show_bug.cgi?id=1644848
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.
[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/qemu-devel@nongnu.org/msg561877.html |
## Bug ##
There are conditions where old qemu/libvirt created guests with the osxsafe cpu feature:
<feature policy='require' name='osxsave'/>
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):
=> https://bugzilla.redhat.com/show_bug.cgi?id=1644848
## 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.
[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/qemu-devel@nongnu.org/msg561877.html |
|
| 2019-04-18 09:38:29 |
Christian Ehrhardt |
description |
## Bug ##
There are conditions where old qemu/libvirt created guests with the osxsafe cpu feature:
<feature policy='require' name='osxsave'/>
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):
=> https://bugzilla.redhat.com/show_bug.cgi?id=1644848
## 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.
[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/qemu-devel@nongnu.org/msg561877.html |
## 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):
=> https://bugzilla.redhat.com/show_bug.cgi?id=1644848
## 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.
[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/qemu-devel@nongnu.org/msg561877.html |
|
| 2019-04-18 09:38:31 |
Christian Ehrhardt |
summary |
qemu lost osxsave feature bit (ok) which might cause upgrade issues (not so ok) |
qemu dropped osxsave/ospke feature triggering upgrade issues |
|
| 2019-04-18 12:39:12 |
Christian Ehrhardt |
description |
## 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):
=> https://bugzilla.redhat.com/show_bug.cgi?id=1644848
## 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.
[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/qemu-devel@nongnu.org/msg561877.html |
## 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):
=> https://bugzilla.redhat.com/show_bug.cgi?id=1644848
## 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.
Obviously it also triggers if:
- libvirt XML with added <feature policy='require' name='osxsave'/>
- virt-install with --cpu ...,+osxsave / ospke
[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/qemu-devel@nongnu.org/msg561877.html
[4]: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1825195/comments/14 |
|
| 2019-04-18 12:40:21 |
Christian Ehrhardt |
description |
## 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):
=> https://bugzilla.redhat.com/show_bug.cgi?id=1644848
## 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.
Obviously it also triggers if:
- libvirt XML with added <feature policy='require' name='osxsave'/>
- virt-install with --cpu ...,+osxsave / ospke
[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/qemu-devel@nongnu.org/msg561877.html
[4]: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1825195/comments/14 |
## 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.
Obviously it also triggers if:
- libvirt XML with added <feature policy='require' name='osxsave'/>
- virt-install with --cpu ...,+osxsave / ospke
[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/qemu-devel@nongnu.org/msg561877.html
[4]: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1825195/comments/14
[5]: https://bugzilla.redhat.com/show_bug.cgi?id=1644848 |
|
| 2019-04-18 13:29:52 |
Christian Ehrhardt |
description |
## 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.
Obviously it also triggers if:
- libvirt XML with added <feature policy='require' name='osxsave'/>
- virt-install with --cpu ...,+osxsave / ospke
[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/qemu-devel@nongnu.org/msg561877.html
[4]: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1825195/comments/14
[5]: https://bugzilla.redhat.com/show_bug.cgi?id=1644848 |
## 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.
Obviously it also triggers if:
- libvirt XML with added <feature policy='require' 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'/>
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/qemu-devel@nongnu.org/msg561877.html
[4]: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1825195/comments/14
[5]: https://bugzilla.redhat.com/show_bug.cgi?id=1644848 |
|
| 2019-04-18 13:29:56 |
Christian Ehrhardt |
libvirt (Ubuntu): status |
New |
Triaged |
|
| 2019-04-18 13:30:01 |
Christian Ehrhardt |
qemu (Ubuntu): status |
New |
Triaged |
|
| 2019-04-18 13:30:04 |
Christian Ehrhardt |
qemu (Ubuntu): importance |
Undecided |
Medium |
|
| 2019-04-18 13:30:06 |
Christian Ehrhardt |
libvirt (Ubuntu): importance |
Undecided |
Medium |
|
| 2019-04-25 12:17:37 |
Christian Ehrhardt |
description |
## 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.
Obviously it also triggers if:
- libvirt XML with added <feature policy='require' 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'/>
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/qemu-devel@nongnu.org/msg561877.html
[4]: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1825195/comments/14
[5]: https://bugzilla.redhat.com/show_bug.cgi?id=1644848 |
## 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='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='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/qemu-devel@nongnu.org/msg561877.html
[4]: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1825195/comments/14
[5]: https://bugzilla.redhat.com/show_bug.cgi?id=1644848 |
|
| 2019-04-25 12:23:16 |
Christian Ehrhardt |
description |
## 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='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='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/qemu-devel@nongnu.org/msg561877.html
[4]: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1825195/comments/14
[5]: https://bugzilla.redhat.com/show_bug.cgi?id=1644848 |
## 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. The same applies to "disable" which would pass the pre-check but then let new qemu fail.
Obviously it also triggers if:
- 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='optional' name='osxsave'/>
<feature policy='optional' name='ospke'/>
Or the same with disable instead of optional.
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/qemu-devel@nongnu.org/msg561877.html
[4]: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1825195/comments/14
[5]: https://bugzilla.redhat.com/show_bug.cgi?id=1644848 |
|
| 2019-04-25 12:26:40 |
Christian Ehrhardt |
description |
## 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. The same applies to "disable" which would pass the pre-check but then let new qemu fail.
Obviously it also triggers if:
- 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='optional' name='osxsave'/>
<feature policy='optional' name='ospke'/>
Or the same with disable instead of optional.
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/qemu-devel@nongnu.org/msg561877.html
[4]: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1825195/comments/14
[5]: https://bugzilla.redhat.com/show_bug.cgi?id=1644848 |
## Bug ##
There are conditions where old qemu/libvirt created guests with the osxsafe or ospke cpu feature:
<feature policy='disable' name='osxsave'/>
<feature policy='optional' 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. The same applies to "disable" which would pass the pre-check but then let new qemu fail.
Obviously it also triggers if:
- 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='optional' name='osxsave'/>
<feature policy='optional' name='ospke'/>
Or the same with disable instead of optional.
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/qemu-devel@nongnu.org/msg561877.html
[4]: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1825195/comments/14
[5]: https://bugzilla.redhat.com/show_bug.cgi?id=1644848 |
|
| 2019-04-25 12:39:20 |
Christian Ehrhardt |
description |
## Bug ##
There are conditions where old qemu/libvirt created guests with the osxsafe or ospke cpu feature:
<feature policy='disable' name='osxsave'/>
<feature policy='optional' 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. The same applies to "disable" which would pass the pre-check but then let new qemu fail.
Obviously it also triggers if:
- 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='optional' name='osxsave'/>
<feature policy='optional' name='ospke'/>
Or the same with disable instead of optional.
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/qemu-devel@nongnu.org/msg561877.html
[4]: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1825195/comments/14
[5]: https://bugzilla.redhat.com/show_bug.cgi?id=1644848 |
[Impact]
* Newer qemu dropped a few features (that never worked) without
deprecation period. In some edge cases that might trigger qemu no more
starting at all.
* Fix by backporting the upstream fix (in those Ubuntu releases that have
an affected qemu, which means >=Disco)
[Test Case]
* Define a lbivirt Guest in your preferred style (uvtool / virt-install /
...).
* Shutdown the guest and then modify it to contain the following:
<cpu mode='custom' match='exact' check='partial'>
<model fallback='allow'>core2duo</model>
<feature policy='disable' name='osxsave'/>
<feature policy='disable' name='ospke'/>
</cpu>
* Start the guest again.
Without the fix it will fail and show:
... Property '.osxsave' not found
[Regression Potential]
* The features never did anything to qemu (which is the reason they got
dropped), so there can#t be an actual feature regression.
The one issue I could imagine is if people prior to Disco were used to
check their qemu cmdline and expect ospke/osxsave to be there.
Those people will now see it gone (but if it is there in there case
they are affected by this bug and their guests won't start anymore). So
those people affected by this corner case are exactly thos ethat would
most likely want the fix.
[Other Info]
* n/a
---
## Bug ##
There are conditions where old qemu/libvirt created guests with the osxsafe or ospke cpu feature:
<feature policy='disable' name='osxsave'/>
<feature policy='optional' 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. The same applies to "disable" which would pass the pre-check but then let new qemu fail.
Obviously it also triggers if:
- 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='optional' name='osxsave'/>
<feature policy='optional' name='ospke'/>
Or the same with disable instead of optional.
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/qemu-devel@nongnu.org/msg561877.html
[4]: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1825195/comments/14
[5]: https://bugzilla.redhat.com/show_bug.cgi?id=1644848 |
|
| 2019-04-25 12:39:35 |
Christian Ehrhardt |
nominated for series |
|
Ubuntu Eoan |
|
| 2019-04-25 12:39:35 |
Christian Ehrhardt |
bug task added |
|
qemu (Ubuntu Eoan) |
|
| 2019-04-25 12:39:35 |
Christian Ehrhardt |
bug task added |
|
libvirt (Ubuntu Eoan) |
|
| 2019-04-25 12:39:35 |
Christian Ehrhardt |
nominated for series |
|
Ubuntu Disco |
|
| 2019-04-25 12:39:35 |
Christian Ehrhardt |
bug task added |
|
qemu (Ubuntu Disco) |
|
| 2019-04-25 12:39:35 |
Christian Ehrhardt |
bug task added |
|
libvirt (Ubuntu Disco) |
|
| 2019-04-25 12:40:24 |
Christian Ehrhardt |
qemu (Ubuntu Eoan): status |
Triaged |
Won't Fix |
|
| 2019-04-25 12:40:26 |
Christian Ehrhardt |
qemu (Ubuntu Disco): status |
New |
Won't Fix |
|
| 2019-04-25 12:40:31 |
Christian Ehrhardt |
libvirt (Ubuntu Disco): status |
New |
Triaged |
|
| 2019-04-25 12:40:33 |
Christian Ehrhardt |
libvirt (Ubuntu Eoan): status |
Triaged |
In Progress |
|
| 2019-05-17 02:01:57 |
Launchpad Janitor |
libvirt (Ubuntu Eoan): status |
In Progress |
Fix Released |
|
| 2019-05-17 02:01:57 |
Launchpad Janitor |
cve linked |
|
2018-12126 |
|
| 2019-05-17 02:01:57 |
Launchpad Janitor |
cve linked |
|
2018-12127 |
|
| 2019-05-17 02:01:57 |
Launchpad Janitor |
cve linked |
|
2018-12130 |
|
| 2019-05-17 02:01:57 |
Launchpad Janitor |
cve linked |
|
2019-11091 |
|
| 2019-05-17 05:40:49 |
Christian Ehrhardt |
qemu (Ubuntu): status |
Triaged |
Won't Fix |
|
| 2019-05-21 18:43:21 |
Brian Murray |
libvirt (Ubuntu Disco): status |
Triaged |
Fix Committed |
|
| 2019-05-21 18:43:25 |
Brian Murray |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2019-05-21 18:43:29 |
Brian Murray |
bug |
|
|
added subscriber SRU Verification |
| 2019-05-21 18:43:33 |
Brian Murray |
tags |
|
verification-needed verification-needed-disco |
|
| 2019-05-22 06:53:03 |
Christian Ehrhardt |
tags |
verification-needed verification-needed-disco |
verification-done verification-done-disco |
|
| 2019-05-30 08:15:10 |
Launchpad Janitor |
libvirt (Ubuntu Disco): status |
Fix Committed |
Fix Released |
|
| 2019-05-30 08:16:59 |
Launchpad Janitor |
libvirt (Ubuntu Disco): status |
Fix Committed |
Fix Released |
|
| 2019-05-30 08:17:30 |
Łukasz Zemczak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
