Laszlo Ersek
2022-Jul-22 07:36 UTC
[Libguestfs] [v2v PATCH v2] output/create_libvirt_xml: relax VCPU feature checking for "qemu64"
When the source domain doesn't specify a VCPU model ("s_cpu_model"
is
None), and the guest OS is assumed to work with the default VCPU model
("gcaps_default_cpu" is true), we don't output any <cpu>
element. In that
case, libvirtd augments the domain config with:
[1] <cpu mode='custom' match='exact'
check='none'>
<model fallback='forbid'>qemu64</model>
</cpu>
where the @check='none' attribute ensures that the converted domain will
be launched, for example, on an Intel host, despite the "qemu64" VCPU
model containing AMD-only feature flags such as "svm".
However, if the source domain explicitly specifies the "qemu64" model
(mostly seen with "-i libvirt -ic qemu://..."), we presently output
[2] <cpu match='minimum'>
<model fallback='allow'>qemu64</model>
</cpu>
which libvirtd completes as
[3] <cpu mode='custom' match='minimum'
check='partial'>
<model fallback='allow'>qemu64</model>
</cpu>
In [3], cpu/@match='minimum' and cpu/model/@fallback='allow' are
both
laxer than @match='exact' and @fallback='forbid', respectively,
in [1].
However, cpu/@check='partial' in [3] is stricter than
@check='none' in
[1]; it causes libvirtd to catch the "svm" feature flag on an Intel
host,
and prevents the converted domain from starting.
The "qemu64" VCPU model is supposed to run on every possible host
<https://gitlab.com/qemu-project/qemu/-/blob/master/docs/system/cpu-models-x86.rst.inc>,
therefore make an exception for the explicitly specified "qemu64" VCPU
model, and generate the @check='none' attribute.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2107503
Signed-off-by: Laszlo Ersek <lersek at redhat.com>
---
Notes:
v2:
- make the attribute dependent on "qemu64" [Rich]
- retrofit the commit message
v1:
- https://listman.redhat.com/archives/libguestfs/2022-July/029504.html
output/create_libvirt_xml.ml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/output/create_libvirt_xml.ml b/output/create_libvirt_xml.ml
index 531a4f75bf3e..bd01304df674 100644
--- a/output/create_libvirt_xml.ml
+++ b/output/create_libvirt_xml.ml
@@ -192,6 +192,8 @@ let create_libvirt_xml ?pool source inspect
List.push_back cpu_attrs ("mode",
"host-passthrough");
| Some model ->
List.push_back cpu_attrs ("match", "minimum");
+ if model = "qemu64" then
+ List.push_back cpu_attrs ("check", "none");
(match source.s_cpu_vendor with
| None -> ()
| Some vendor ->
--
2.19.1.3.g30247aa5d201
Richard W.M. Jones
2022-Jul-22 09:35 UTC
[Libguestfs] [v2v PATCH v2] output/create_libvirt_xml: relax VCPU feature checking for "qemu64"
On Fri, Jul 22, 2022 at 09:36:27AM +0200, Laszlo Ersek wrote:> When the source domain doesn't specify a VCPU model ("s_cpu_model" is > None), and the guest OS is assumed to work with the default VCPU model > ("gcaps_default_cpu" is true), we don't output any <cpu> element. In that > case, libvirtd augments the domain config with: > > [1] <cpu mode='custom' match='exact' check='none'> > <model fallback='forbid'>qemu64</model> > </cpu> > > where the @check='none' attribute ensures that the converted domain will > be launched, for example, on an Intel host, despite the "qemu64" VCPU > model containing AMD-only feature flags such as "svm". > > However, if the source domain explicitly specifies the "qemu64" model > (mostly seen with "-i libvirt -ic qemu://..."), we presently output > > [2] <cpu match='minimum'> > <model fallback='allow'>qemu64</model> > </cpu> > > which libvirtd completes as > > [3] <cpu mode='custom' match='minimum' check='partial'> > <model fallback='allow'>qemu64</model> > </cpu> > > In [3], cpu/@match='minimum' and cpu/model/@fallback='allow' are both > laxer than @match='exact' and @fallback='forbid', respectively, in [1]. > > However, cpu/@check='partial' in [3] is stricter than @check='none' in > [1]; it causes libvirtd to catch the "svm" feature flag on an Intel host, > and prevents the converted domain from starting. > > The "qemu64" VCPU model is supposed to run on every possible host > <https://gitlab.com/qemu-project/qemu/-/blob/master/docs/system/cpu-models-x86.rst.inc>, > therefore make an exception for the explicitly specified "qemu64" VCPU > model, and generate the @check='none' attribute. > > Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2107503 > Signed-off-by: Laszlo Ersek <lersek at redhat.com> > --- > > Notes: > v2: > - make the attribute dependent on "qemu64" [Rich] > - retrofit the commit message > > v1: > - https://listman.redhat.com/archives/libguestfs/2022-July/029504.html > > output/create_libvirt_xml.ml | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/output/create_libvirt_xml.ml b/output/create_libvirt_xml.ml > index 531a4f75bf3e..bd01304df674 100644 > --- a/output/create_libvirt_xml.ml > +++ b/output/create_libvirt_xml.ml > @@ -192,6 +192,8 @@ let create_libvirt_xml ?pool source inspect > List.push_back cpu_attrs ("mode", "host-passthrough"); > | Some model -> > List.push_back cpu_attrs ("match", "minimum"); > + if model = "qemu64" then > + List.push_back cpu_attrs ("check", "none"); > (match source.s_cpu_vendor with > | None -> () > | Some vendor ->ACK - but see also: https://listman.redhat.com/archives/libguestfs/2022-July/029520.html Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top