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. > 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. > 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. > That, and update the API documentation for > virConnectGetMaxVcpus() to notify applications developers that > they should really use the domcapabilities XML instead. But yeah, we should update the docs this way. Jirka -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list