Re: [libvirt] [PATCH 10/22] virsh: Introduce new hypervisor-cpu-compare command
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