On Fri, May 25, 2018 at 15:22:43 -0400, Collin Walling wrote:
> >>> + switch (result) {
> >>> + case VIR_CPU_COMPARE_INCOMPATIBLE:
> >>> + vshPrint(ctl,
> >>> + _("CPU described in %s is incompatible with the CPU
> >>> provided "
> >>> + "by hypervisor on the host\n"),
> >>> + from);
> >>
> >> How much information regarding a CPU definition does libvirt consider when
> >> comparing CPU's
> >> for x86 (and for other archs, if you happen to know)? On s390, we only
> >> take the cpu model
> >> and features into consideration.
> >>
> >> If the archs other than s390 will only use the cpu model and features as
> >> well -- or if this
> >> API should explicitly work only with CPU models -- then perhaps it is more
> >> accurate for these
> >> messages to state "CPU model" instead of "CPU"? This change would also
> >> have to be propagated
> >> in to the documentation, replacing "CPU definition" with "CPU model".
> >
> > It doesn't really matter what libvirt currently checks for which
> > architecture. The API takes a CPU definition XML and libvirt will use
> > anything it needs from that.
> >
>
> I had to bat this around in my head a bit. Truthfully, I think trying to
> expand on
> why we got the result might be a little much.
That's (partially) the reason behind --error option. It will cause the
API to return an error (rather than VIR_CPU_COMPARE_INCOMPATIBLE) and
you can check the error messages for details about the incompatibility.
For example, the x86 CPU driver will list all missing features.
> Perhaps I should have more faith in the user to understand what is
> taken into consideration when CPUs are compared :)
The user should not really need to know what is used for comparison.
They would just have a CPU definition they want to use for a guest and
this API can be used to check whether such CPU can be run on a given
host.
For example, oVirt has a set of CPU definitions from which a user can
select and calls the compare API to check which hosts can run which CPU
so that they can properly schedule where to run individual VMs.
Jirka
--
libvir-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/libvir-list
