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