On 02/13/2014 06:50 AM, Claudio Bley wrote:
The docs say:
> If the guest is inactive, this is basically the same as
> virConnectGetMaxVcpus(). If the guest is running this will reflect
> the maximum number of virtual CPUs the guest was booted with.
But, apparently, all the driver implementations for
virDomainGetMaxVcpus forward to
<driver>DomainGetVcpusFlags(.., VIR_DOMAIN_AFFECT_LIVE | VIR_DOMAIN_VCPU_MAXIMUM).
_______________________________,~~~~~~~~~~~~~~~~~~~~~~
Looks like I caused a regression when I added the Flags variant in 2010
(that was my first real API addition when I was new to libvirt coding,
if I recall). Fixing the code to match the docs sounds like the right
way to go here.
To be honest, I'm not sure whether this worked as described at some
time in the past _at all_.
How to fix this? Change the documentation or the flag?
The newer Flags API should be preferred, but that doesn't mean we can't
fix the older API to behave more sanely. On the back-compat
perspective, changing something that used to fail into something that
now succeeds is okay (you can tell whether you are talking to an older
libvirt by whether the failure happens). [The opposite direction of
changing something that succeeds into an error is not nice unless it is
done to plug a security hole, since older code may be depending on the
success path and should not need to be rewritten to new API just to keep
things working]
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org