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@xxxxxxxxxxxxxxxxxx> > > --- > > 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list