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 <lersek(a)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