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