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