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

Jiri Denemark jdenemar at redhat.com
Thu May 5 08:00:26 UTC 2016


On Thu, May 05, 2016 at 09:34:21 +0200, Andrea Bolognani wrote:
> On Thu, 2016-05-05 at 08:52 +0200, Jiri Denemark wrote:
> > 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.
> 
> The fact is that the QEMU limit *does* influence the actual
> limit for KVM guests: see the example above, taken from a
> POWER host, where KVM would happily create 2048 vCPUs but QEMU
> is limited to 255.
> 
> I didn't say it explicitly, but it was implied that QEMU limits
> would only be present for QEMU and KVM guests, and KVM limits
> only for KVM guests.
> 
> I guess we could skip all the details and just give the user
> 
>   <vcpus max='255' suggested='96'/>
> 
> so they don't have to implement the logic themselves. But
> reporting the KVM limits without taking QEMU limits into
> consideration is not the way to go, I think.

Yes. I didn't want to say we should only report the number from KVM, I
meant we should only show the number that is applicable to a KVM domain
of the particular machine type. That is, both KVM and QEMU limits
combined into a single number which gives the real limit.

Jirka




More information about the libvir-list mailing list