> Indeed I did say that a virsh command based on GetDomainCapabilities
> was OK, but that is not what this series is doing.
>
> This is essentially the same as the old series, adding a new public
> virConnectGetHypervisorCPUModelNames API, which virsh then calls.
>
> virsh needs to call virConnectGetDomainCapabilities directly if we
> want a 'hypervisor-cpu-models' command.
Thanks for your feedback. It seems we have a disconnect with respect to
how this should be designed.
The first iteration I posted some time back pulled the CPU models
directly from the qemuCaps. This iteration instead pulls from the
domCaps, which I thought met the requirements of the feedback since both
the proposed API and existing virConnectGetDomainCapabilities interface
extract data from this structure. From my perspective, it makes sense
to extract the CPU models directly from the data structure and format
the output as desired versus adding an extra step to parse the XML.
This is my understanding of the operations of both approaches if the
steps were to be unfurled:
1. proposed API operations:
Retrieve hypervisor caps -> extract domain caps -> extract CPU
models -> print to stdout
2. virConnectGetDomainCapabilities operations:
Retrieve hypervisor caps -> extract domain caps -> format into XML
-> parse CPU models -> print to stdout
My goal is to work together to clear up any misunderstandings by laying
out the design as much as possible so we can agree on the approach for
the next iteration.
--
Regards,
Collin
