[libvirt] [PATCH v2] Get the maxvcpus from both the qemuCaps and /dev/kvm

[Jiri Denemark]

On Wed, May 04, 2016 at 10:12:24 -0400, Cole Robinson wrote:
> On 05/04/2016 08:34 AM, Shivaprasad G Bhat wrote:
> > For some archs and machines, the maxvcpus defined in the kernel can be different
> > from the qemu-caps maxvcpus. Just reporting the kernel defined maxvcpus is not
> > be sufficient. virsh domacapabilities and virsh maxvcpus --type kvm return
> > different maxvcpus values and is confusing as to know what actually works.
> > The minimum of the two values is what actually works.
> > 
> > For example on PPC64, the KVM_MAX_VCPUS is defined to be 1024 in kernel
> > where as qemu has MAX_CPUMASK_BITS defined at 255 in include/sysemu/sysemu.h.
> > The guest can go upto 256 vcpus here.
> > 
> > Signed-off-by: Shivaprasad G Bhat <sbhat at linux.vnet.ibm.com>
> > ---
> >  src/qemu/qemu_driver.c |   27 ++++++++++++++++++++++++---
> >  1 file changed, 24 insertions(+), 3 deletions(-)
> > 
> 
> You'll also need to extend the virConnectGetMaxVcpus doc string in
> src/libvirt-host.c to indicate it may limit the reported CPUs based on host
> arch and default machine type.

Hmm, I think it is a very bad idea to limit the CPUs according to
something which is hidden and you cannot influence. In other words, the
API itself is not able to report the maximum depending on emulator
binary, machine type, whatever so it shouldn't do that at all. Using
default emulator and machine type is even more confusing that reporting
just the kernel limits.

The virConnectGetDomainCapabilities API seems like a much better place
for reporting maximum number of usable CPUs as it can get kvm/qemu,
arch, emulator binary, and machine type as optional parameters so that
the user gets the answer they want rather than just (in various ways)
random number reported by virConnectGetMaxVcpus.

Jirka