Revisiting the virsh hypervisor-cpu-models/definitions commands

[Jiri Denemark]

On Wed, May 17, 2023 at 17:34:46 -0400, Collin Walling wrote:
> 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.

Sure, if you already know exactly what CPU your other host runs on you
don't need to fetch domcapabilities from there. But if you don't know
this info there's no way you could compute a baseline CPU without asking
the other host.

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

What data would hypervisor-cpu-models provide that are not already
reported in domain capabilities XML?

    <mode name='custom' supported='yes'>
      <model usable='no' vendor='IBM'>gen16a-base</model>
      <model usable='no' vendor='IBM'>gen16a</model>
      <model usable='yes' vendor='IBM'>z800-base</model>
      <model usable='no' vendor='IBM'>z890.2-base</model>
      <model usable='no' vendor='IBM'>z9EC.2</model>
      <model usable='no' vendor='IBM'>z13.2</model>
      <model usable='no' vendor='IBM'>z990.5-base</model>
      ...
    </mode>

Unless it's something crazy I think we should be able to extend the XML
with such info rather then creating a dedicated API for it.

> Now I can feed that string into hypervisor-cpu-definitions and get a
> proper XML-formatted CPU model.

I think I'm missing something here, but what would such API do with the
CPU model string in addition to

    <cpu mode="custom" match="exact">
      <model>z14.2-base</model>
    </cpu>

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

As mentioned above, the "query a remote machine for their host-model"
step is for checking what CPU the hosts are running on. You can of
course substitute this step with "I know the CPU models already". And
once you have that info you do all the rest on a single host.

I believe this could already be done with the existing APIs we have.
Could you please explain what parts are missing?

Jirka