On Tue, Feb 07, 2023 at 01:25:34PM +0100, Laszlo Ersek wrote: > On 2/7/23 09:46, Richard W.M. Jones wrote: > > For RHEL >= 9 / x86-64 guests we cannot use the default qemu CPU > > (eg. "qemu64"), and so we have a mechanism for conversion to indicate > > to the output modes that a more capable CPU is required. We > > previously picked cpu='host-passthrough' (ie. the equivalent of qemu's > > -cpu host). However this is not live migratable. cpu='host-model' is > > a better choice as it is more likely to be migratable. > > > > See also discussion here: > > https://listman.redhat.com/archives/libguestfs/2023-February/030625.html > > --- > > output/create_libvirt_xml.ml | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/output/create_libvirt_xml.ml b/output/create_libvirt_xml.ml > > index e3dac4d894..60977cf5bb 100644 > > --- a/output/create_libvirt_xml.ml > > +++ b/output/create_libvirt_xml.ml > > @@ -193,7 +193,7 @@ let create_libvirt_xml ?pool source inspect > > (match source.s_cpu_model with > > | None -> > > if not guestcaps.gcaps_default_cpu then > > - List.push_back cpu_attrs ("mode", "host-passthrough"); > > + List.push_back cpu_attrs ("mode", "host-model"); > > | Some model -> > > List.push_back cpu_attrs ("match", "minimum"); > > if model = "qemu64" then > > Ah, *now* I remember. Seeing the proposal in patch form certainly jogs > my memory! :) > > We added the code being patched above in commit a3e45b3ea5b4 > ("create_libvirt_xml: honor "gcaps_default_cpu"", 2022-04-22). > > Consistently with that, grandchild commit 8e4eaeaeb248 ("output_qemu: > honor "gcaps_default_cpu"", 2022-04-22) would make the same argument > ("migration is not a goal"), and translate "not (gcaps_default_cpu)" to > "-cpu host" on the command line. > > In other words, the idea was to handle this uniformly between the QEMU > and libvirt outputs. The messages on commits a3e45b3ea5b4 and > 8e4eaeaeb248 are nearly identical -- I clearly only meant to translate > the same idea to both different outputs. We discussed libvirtd's > "host-model" back then (IIRC), and it invokes some nifty libvirtd logic > that we cannot redo for the QEMU command line ourselves (and QEMU also > does not offer it). > > So, with this patch, we'd diverge from that uniformity. > > It's fine though IMO; we can just say that we never want to migrate > guests converted to "QEMU cmdline" format, yet we want to do it with > libvirt ones. IOW migration under libvirt is more important than > uniformity between QEMU and libvirt.
I'm not actually sure if it's possible to do live migration of a guest which is started from a shell script which runs qemu. Maybe if you manually used the HMP console?? But yes, let's make it slightly non-uniform, for a slightly better experience for libvirt users. > Acked-by: Laszlo Ersek <ler...@redhat.com> Thanks, upstream in 12473bfcb7. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org _______________________________________________ Libguestfs mailing list Libguestfs@redhat.com https://listman.redhat.com/mailman/listinfo/libguestfs
