[libvirt] [PATCH v2] kvm: warn if num cpus is greater than num recommended

[Andrew Jones]

----- Original Message -----
> On 08/23/2013 07:24 AM, Andrew Jones wrote:
> > The comment in kvm_max_vcpus() states that it's using the recommended
> > procedure from the kernel API documentation to get the max number
> > of vcpus that kvm supports. It is, but by always returning the
> > maximum number supported. The maximum number should only be used
> > for development purposes. qemu should check KVM_CAP_NR_VCPUS for
> > the recommended number of vcpus. This patch adds a warning if a user
> > specifies a number of cpus between the recommended and max.
> > 
> > v2:
> > Incorporate tests for max_cpus, which specifies the maximum number
> > of hotpluggable cpus. An additional note is that the message for
> > the fail case was slightly changed, 'exceeds max cpus' to
> > 'exceeds the maximum cpus'. If this is unacceptable change for
> > users like libvirt, then I'll need to spin a v3.
> 
> A quick grep of libvirt does not show any dependence on the particular
> wording "exceeds max cpus", so you are probably fine changing that.
> 
> What I'm more worried about is what number is libvirt supposed to show
> to the end user, and should libvirt enforce the lower recommended max,
> or the larger kernel absolute max?  Which of the two values does the QMP
> 'MachineInfo' type return in its 'cpu-max' field during the
> 'query-machines' command?  Should we be modifying QMP to return both
> values, so that libvirt can also expose the logic to the end user of
> allowing a recommended vs. larger development max?
> 

Machine definitions maintain yet another 'max_cpus'. And it appears that
qmp would return that value. It would probably be best if it returned
max(qemu_machine.max_cpus, kvm_max_cpus) though.
 
I'm starting to think that we should just keep things simple for most of
the virt stack by sticking to enforcing the larger developer max. And
then on a production kernel we should just compile KVM_MAX_VCPUS =
KVM_SOFT_MAX_VCPUS and be done with it. With that thought, this patch
could be dropped too. The alternative seems to be supporting a run-time
selectable experimental mode throughout the whole virt stack.

drew