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@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list