[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@redhat.com>
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@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
participants (2)
-
Laszlo Ersek -
Richard W.M. Jones