Re: Revisiting the virsh hypervisor-cpu-models/definitions commands
On Wed, May 17, 2023 at 05:34:46PM -0400, Collin Walling wrote:
I believe that these commands will assist a user in creating a
migration-safe CPU model for a guest in a mixed-generation host
environment without having to query details from a remote machine.
Say I have two machines, a z14 and a z15. If I wanted to know which
CPU model I should define my guest with such that I can guarantee a
future migration between the two machines, I would need to run
domcapabilities on one machine, then transfer it to the other machine
to then perform a baseline. I believe this process could be simplified
and remove the need to query a remote machine for its CPU definition.
With hypervisor-cpu-models, I can get a list of CPU models and their
exact names that I'd like to consider in my mixed environment. Let's
say I'm on my z15 machine. I want the name of the appropriate z14
model. I run the hypervisor-cpu-models command and I see that the
appropriate model for a z14 is a z14.2-base. Now I can feed that string
into hypervisor-cpu-definitions and get a proper XML-formatted CPU
model. This XML can be fed into hypervisor-cpu-baseline, and produce a
CPU model that can run on both a z14 and z15. I was able to compute a
migration-safe CPU model for my mixed environment without having to
query a remote machine for their host-model.
IIUC, you only avoided querying the remote machine becasue you already
knew ahead of time that the remote machine was a z14. But even that is
potentially wrong, because there was an implicit assumption built-in
there, that the QEMU version on the remote host supports all the same
CPU models as the QEMU on the local host.
There may be more complex examples that help support this idea, but
the
main point is that a user can compute a CPU model from a single libvirt
instance instead of having to query details from multiple machines. This
is achieved by having a set of hypervisor-cpu-* commands to work with.
Computing a CPU model from a single libvirt instance can only ever
work if you already know what hardware all the other machines are
running, and that they have the same QEMU version available. If
you already know what the other machines are using I'm doubtful
you need to use the libvirt APIs at all. All that's needed is to
see a list of supported QEMU CPU models, and pick the one that's
obviously a match.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|