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