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

Jiri Denemark jdenemar at redhat.com
Thu May 5 06:52:18 UTC 2016

On Wed, May 04, 2016 at 19:27:41 +0200, Andrea Bolognani wrote:
> How about something like
>   <vcpus max='255'>
>     <kvm>
>       <soft_limit>96</soft_limit>
>       <hard_limit>2048</hard_limit>
>     </kvm>
>     <qemu>
>       <hard_limit>255</hard_limit>
>     </qemu>
>   </vcpus>

No, domcapabilities are bound to an arch/binary/type/machine-type
combination so providing both kvm and qemu stuff there is wrong. If it's
a result of asking for kvm type, //vcpus at max should contain the kvm
limit. If the type of the domain is qemu, it should contain qemu limit.
And in both cases, the limit is constrained to just the machine type
reported in the domcapabilities XML.

> This would include one bit of information that AFAIK we're
> currently missing, which is the recommended number of vCPUs;
> the maximum value would of course be the smallest amoung all
> hard limits.

We could perhaps somehow incorporate the "recommended number of CPUs" in
there, but that's a separate thing really.

> And of course we can't change virConnectGetMaxVcpus() because
> it's public API, but we can extend 'virsh maxvcpus' to accept
> the same options as 'virsh domcapabilities' and actually use
> the domcapabilities XML behind the scenes.

I don't think this is a good idea.

> That, and update the API documentation for
> virConnectGetMaxVcpus() to notify applications developers that
> they should really use the domcapabilities XML instead.

But yeah, we should update the docs this way.


More information about the libvir-list mailing list