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