On Wed, 2016-05-04 at 10:44 -0400, Cole Robinson wrote: > > Hmm, I think it is a very bad idea to limit the CPUs according to > > something which is hidden and you cannot influence. In other words, the > > API itself is not able to report the maximum depending on emulator > > binary, machine type, whatever so it shouldn't do that at all. Using > > default emulator and machine type is even more confusing that reporting > > just the kernel limits. > > Is it not confusing that MaxVCPUs will return a value that no VM can actually > support, because it hits qemu limits? That was the original complaint. > > Maybe instead we do MIN(kvm_vcpus, max_vcpus_supported_by_any_qemu_machine) > > Even if we don't change the logic, the API documentation could use some work > to clarify the existing behavior > > > The virConnectGetDomainCapabilities API seems like a much better place > > for reporting maximum number of usable CPUs as it can get kvm/qemu, > > arch, emulator binary, and machine type as optional parameters so that > > the user gets the answer they want rather than just (in various ways) > > random number reported by virConnectGetMaxVcpus. > > I agree the proper place for reporting fully accurate info is in domcapabilities 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> Hopefully someone can come up with a better XML than that, but you get the idea :) 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. 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. That, and update the API documentation for virConnectGetMaxVcpus() to notify applications developers that they should really use the domcapabilities XML instead. -- Andrea Bolognani Software Engineer - Virtualization Team -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list