Quoting Jiri Denemark (2018-05-28 09:19:51)
On Wed, May 16, 2018 at 10:39:19 +0200, Jiri Denemark wrote:
> The current virConnectCompareCPU and virConnectBaselineCPU APIs are not
> very useful because they ignore what a hypervisor can do on the current
> host. This series adds two new APIs which are designed to work with
> capabilities of a specific hypervisor to provide usable results.
>
> The third CPU related API virConnectGetCPUModelNames is pretty useless
> too, but no new API with similar functionality is needed because domain
> capabilities XML already contains the relevant data.
I made the suggested changes and pushed the series. Thanks for the
reviews.
Jirka
Hi Jirka,
FYI I reviewed your patches too and everthing I found that was not already
identified was nitpick stuff but I do have a something I am wondering about...
The new hypervisor specific compare and baseline commands seem to depend on
qemuCaps being pre-populated with model data that is specific to a hypervisor
instance.
How do we make sure the qemuCaps are pre-populated with cpu model data for any
arbitrary hypervisor (with a different exec path, arch, etc) that we can issue
the hypervisor compare or baseline commands against?
Is it a case of executing a virsh command to populate qemuCaps for a non-default
hypervisor prior to issuing the hypervisor compare or baseline commands?
Sorry if a complete noob question or I missed the answer in previous mails.
Chris
--
libvir-list mailing list
libvir-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list