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

[Andrea Bolognani]

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.

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

It seems like a valuable information an a good fit for the
element, but if you have a better placement in mind please do
share :)

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

Why not? virsh is supposed to be both a uselful management tool
and a showcase of our API... If we document that a function does
not provide optimal data, and document the preferred approach
instead, why shouldn't virsh be updated to reflect the changes
we're raccomending external users, thus making it better both
as a management tool and as an API showcase?

-- 
Andrea Bolognani
Software Engineer - Virtualization Team