[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



On 05/04/2016 10:24 AM, Jiri Denemark wrote:
> 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 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.

Is it not confusing that MaxVCPUs will return a value that no VM can actually
support, because it hits qemu limits? That was the original complaint.

Maybe instead we do MIN(kvm_vcpus, max_vcpus_supported_by_any_qemu_machine)

Even if we don't change the logic, the API documentation could use some work
to clarify the existing behavior

> 
> 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.

I agree the proper place for reporting fully accurate info is in domcapabilities

- Cole


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]