Revisiting the virsh hypervisor-cpu-models/definitions commands
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
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
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 :|
On Wed, May 17, 2023 at 05:34:46PM -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.
snip
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
BTW, I should say I didn't have a strong objection to the addition of a 'hypervisor-cpu-models' command per-se. My objection was pointing out that virConnectGetHypervisorCPUNames/hypervisor-cpu-models was duplicating info already exposed by virDomainGetCapabilities/domcapabilities. If you re-propose hypervisor-cpu-models, as a friendly frontend that parses the virDomainGetCapabilities() XML to extract the CPU list, I think that would be justiable. Admittedly I didn't really explain that well in my feedback at the time.
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
My objection to that is that it was creating inconsistent way of representing CPU models, because it was dirrecty exposing QEMU terminology bypassing the libvirt mapping, and it wasn't actually possible to use the exposed names. 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 :|
On 5/26/23 7:35 AM, Daniel P. Berrangé wrote:
On Wed, May 17, 2023 at 05:34:46PM -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.
snip
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
BTW, I should say I didn't have a strong objection to the addition of a 'hypervisor-cpu-models' command per-se. My objection was pointing out that virConnectGetHypervisorCPUNames/hypervisor-cpu-models was duplicating info already exposed by virDomainGetCapabilities/domcapabilities.
If you re-propose hypervisor-cpu-models, as a friendly frontend that parses the virDomainGetCapabilities() XML to extract the CPU list, I think that would be justiable.
Admittedly I didn't really explain that well in my feedback at the time.
It's likely I misinterpreted your feedback on my end as well. I appreciate the clarification. I'll get to work on this once some cycles clear up. I'll start with changing the current hypervisor-cpu- models implementation I drew up, and then we can continue the discussion over there for what would make sense for a hypervisor-cpu-definitions command (if it still makes sense to create that one).
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
My objection to that is that it was creating inconsistent way of representing CPU models, because it was dirrecty exposing QEMU terminology bypassing the libvirt mapping, and it wasn't actually possible to use the exposed names.
Thanks for clearing that up. I don't fully understand how the x86 CPU model schemes are set up in libvirt, so it helps to get some exposure / explanation on that area. I understand your comments now.
With regards, Daniel
participants (3)
-
Collin Walling -
Daniel P. Berrangé -
Jiri Denemark