Revisiting the virsh hypervisor-cpu-models/definitions commands

[Collin Walling]

Daniel, Tim, (and others on the upstream list that'd like to chime in)

Harken back to a few months ago when I presented a few patches to
introduce the virsh hypervisor-cpu-models command. The proposal was
turned down, and I was pointed to a patch-set/discussion that Tim
introduced almost a year ago today. From what I was able to gather with
respect to Tim's patches, it seems like this is not a direction that
x86 wants to pursue, but I still see value in these commands for s390 
(and perhaps other architectures that may/currently implement CPU
models via the hypervisor). I see value in these commands that shine
when including the other hypervisor-cpu-* commands: baseline and comparison.

What I'd like to accomplish with this conversation: is there an
agreement where these virsh commands may be implemented, or at least
some guidance on what should be expected for virsh -> hypervisor CPU
model commands going forward?

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. While this is a
rudimentary example, future models may become more complex as certain
features are removed or deprecated from CPU models (or make it easier
for other architectures that have a non-sequential naming scheme).

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.

For reference, here are links to the patches and discussions:
- Mine I proposed earlier this year (March 2023):
   https://listman.redhat.com/archives/libvir-list/2023-March/238981.html

And here are Tim's:
- Patch Set (June 2022):
   https://listman.redhat.com/archives/libvir-list/2022-June/232626.html

- Follow-up Discussion (July 2022):
   https://listman.redhat.com/archives/libvir-list/2022-July/232891.html

Thanks for your time,
  - Collin