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:
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@max should contain the kvm
On Wed, May 04, 2016 at 19:27:41 +0200, Andrea Bolognani wrote: 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