Re: [Libguestfs] [PATCH v2v] -o libvirt: Use cpu='host-model' for gcaps_default_cpu = false

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.

Acked-by: Laszlo Ersek <lersek(a)redhat.com&gt;