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@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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list