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

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
-- 
2.39.0

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 at redhat.com>