On Wed, 2016-06-15 at 09:56 +0000, Shivaprasad G Bhat wrote: > The API virConnectGetMaxVcpus doesnt really reflect the actual usable number s/doesnt/doesn't/ > of cpus as the maximum limits can be different for kvm and/or qemu. So update > the documentation to use virConnectGetDomainCapabilities() instead. > > Signed-off-by: Shivaprasad G Bhat <sbhat@xxxxxxxxxxxxxxxxxx> > --- > src/libvirt-host.c | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/src/libvirt-host.c b/src/libvirt-host.c > index 24277b7..f6b0c30 100644 > --- a/src/libvirt-host.c > +++ b/src/libvirt-host.c > @@ -313,7 +313,11 @@ virConnectGetSysinfo(virConnectPtr conn, unsigned int flags) > * > * Provides the maximum number of virtual CPUs supported for a guest VM of a > * specific type. The 'type' parameter here corresponds to the 'type' > - * attribute in the <domain> element of the XML. > + * attribute in the <domain> element of the XML. The API doesn't take emulator > + * limits into consideration. Hence the maximum reported here can be limited by > + * the emulator max limits. It is recommended to use the > + * virConnectGetDomainCapabilities() API specifying the emulator details to get > + * the accurate results. I'd reword this slightly, along the lines of This API doesn't take emulator limits into consideration, hence the returned value is not guaranteed to be usable. It is recommended to use virConnectGetDomainCapabilities() and look for <vcpu max='...'> in its output instead. > * > * Returns the maximum of virtual CPU or -1 in case of error. > */ I feel like this patch should actually be last one in the series, after the preferred way to retrieve the information has actually been implemented. -- Andrea Bolognani Software Engineer - Virtualization Team -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list