Laszlo Ersek
2022-Jul-20 11:09 UTC
[Libguestfs] [v2v PATCH] output/create_libvirt_xml: generate @check='none' CPU attribute
We currently don't generate any @check attribute for the /domain/cpu element, which causes the following libvirtd behavior <https://libvirt.org/formatdomain.html#cpu-model-and-topology>:> Once the domain starts, libvirt will automatically change the check > attribute to the best supported value to ensure the virtual CPU does not > change when the domain is migrated to another hostVera Wu reports that in practice, at least when the source CPU model is explicitly "qemu64", libvirtd sets @check='partial'. That's defined as:> Libvirt will check the guest CPU specification before starting a domainThis is a problem: the default "qemu64" CPU model exposes the SVM CPU flag, and that's unsupportable on Intel hosts. SVM is the AMD counterpart of VT-x; IOW, the flag effectively advertizes AMD-specific nesting to guests. With @check='partial', libvirt prevents the converted domain from starting on Intel hosts; but with @check='none',> Libvirt does no checking and it is up to the hypervisor to refuse to > start the domain if it cannot provide the requested CPU. With QEMU this > means no checking is done at all since the default behavior of QEMU is > to emit warnings, but start the domain anyway.We don't care about the migratability of the converted domain, so relax the libvirtd checks, by generating the @check='none' attribute. Consider adding @check='none' in two cases: (1) When the source domain specifies a CPU model. Generating @check='none' in this case fixes the issue reported by Vera. (2) When the source domain does not specify a CPU model, and the guest OS is assumed to work well with the default CPU model. Generating @check='none' in this case is actually a no-op. Going from "no CPU element" to "<cpu check='none'/>" does not change how libvirtd augments the domain config. Namely, (2.1) for x86 guests, we get <cpu mode='custom' match='exact' check='none'> <model fallback='forbid'>qemu64</model> </cpu> either way, (2.2) for aarch64 guests, we get <cpu mode='custom' match='exact' check='none'> <model fallback='forbid'>cortex-a15</model> </cpu> either way. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2107503 Signed-off-by: Laszlo Ersek <lersek at redhat.com> --- output/create_libvirt_xml.ml | 1 + 1 file changed, 1 insertion(+) diff --git a/output/create_libvirt_xml.ml b/output/create_libvirt_xml.ml index 531a4f75bf3e..0343d3194268 100644 --- a/output/create_libvirt_xml.ml +++ b/output/create_libvirt_xml.ml @@ -192,6 +192,7 @@ let create_libvirt_xml ?pool source inspect List.push_back cpu_attrs ("mode", "host-passthrough"); | Some model -> List.push_back cpu_attrs ("match", "minimum"); + 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-20 12:00 UTC
[Libguestfs] [v2v PATCH] output/create_libvirt_xml: generate @check='none' CPU attribute
On Wed, Jul 20, 2022 at 01:09:13PM +0200, Laszlo Ersek wrote:> We currently don't generate any @check attribute for the /domain/cpu > element, which causes the following libvirtd behavior > <https://libvirt.org/formatdomain.html#cpu-model-and-topology>: > > > Once the domain starts, libvirt will automatically change the check > > attribute to the best supported value to ensure the virtual CPU does not > > change when the domain is migrated to another host > > Vera Wu reports that in practice, at least when the source CPU model is > explicitly "qemu64", libvirtd sets @check='partial'. That's defined as:I think my main confusion is why is the _source_ model "qemu64"? Doesn't that imply the source hypervisor is qemu and so we shouldn't use virt-v2v at all? In fact from the BZ: # virt-v2v -i libvirt -ic qemu:///system esx6.7-rhel8.6-nvme-disk ... (Vera is doing this for a good reason - she wants to test the -oo compressed option, and using a local qemu guest is the quickest way.) Anyway let's go with the assumption this is a bad idea, but for testing purposes we often do this so we should try to make it work.> > Libvirt will check the guest CPU specification before starting a domain > > This is a problem: the default "qemu64" CPU model exposes the SVM CPU > flag, and that's unsupportable on Intel hosts. SVM is the AMD counterpart > of VT-x; IOW, the flag effectively advertizes AMD-specific nesting to > guests. > > With @check='partial', libvirt prevents the converted domain from starting > on Intel hosts; but with @check='none', > > > Libvirt does no checking and it is up to the hypervisor to refuse to > > start the domain if it cannot provide the requested CPU. With QEMU this > > means no checking is done at all since the default behavior of QEMU is > > to emit warnings, but start the domain anyway. > > We don't care about the migratability of the converted domain, so relax > the libvirtd checks, by generating the @check='none' attribute.For testing we don't, but in general -o libvirt conversions we might care about migratability.> Consider adding @check='none' in two cases: > > (1) When the source domain specifies a CPU model. > > Generating @check='none' in this case fixes the issue reported by Vera. > > (2) When the source domain does not specify a CPU model, and the guest OS > is assumed to work well with the default CPU model. > > Generating @check='none' in this case is actually a no-op. Going from "no > CPU element" to "<cpu check='none'/>" does not change how libvirtd > augments the domain config. Namely, > > (2.1) for x86 guests, we get > > <cpu mode='custom' match='exact' check='none'> > <model fallback='forbid'>qemu64</model> > </cpu> > > either way, > > (2.2) for aarch64 guests, we get > > <cpu mode='custom' match='exact' check='none'> > <model fallback='forbid'>cortex-a15</model> > </cpu> > > either way. > > Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2107503 > Signed-off-by: Laszlo Ersek <lersek at redhat.com> > --- > output/create_libvirt_xml.ml | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/output/create_libvirt_xml.ml b/output/create_libvirt_xml.ml > index 531a4f75bf3e..0343d3194268 100644 > --- a/output/create_libvirt_xml.ml > +++ b/output/create_libvirt_xml.ml > @@ -192,6 +192,7 @@ let create_libvirt_xml ?pool source inspect > List.push_back cpu_attrs ("mode", "host-passthrough"); > | Some model -> > List.push_back cpu_attrs ("match", "minimum"); > + List.push_back cpu_attrs ("check", "none");So should we make this attribute conditional on the source CPU model being qemu64, just so the change is minimal and we don't break migratability for non testcases? Rich.> (match source.s_cpu_vendor with > | None -> () > | Some vendor -> > -- > 2.19.1.3.g30247aa5d201 > > _______________________________________________ > Libguestfs mailing list > Libguestfs at redhat.com > https://listman.redhat.com/mailman/listinfo/libguestfs-- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v