On Tue, Sep 28, 2010 at 01:36:13PM -0600, Eric Blake wrote:
On 09/27/2010 11:20 AM, Eric Blake wrote:
>No change to existing API semantics, although the implementation can
>wrap old APIs to call the new ones with appropriate flags where
>appropriate to minimize code duplication.
One more API to think about:
virDomainGetInfo returns a virDomainInfoPtr, where that struct
includes an unsigned short nrVirtCpu member. I'm assuming that
since this is a public struct involved in on-the-wire RPC protocol,
we can't change it to add a new member (and it also implicitly means
that we are limited to 64k vcpus, even though the unsigned int
argument of virDomainSetVcpus could otherwise go larger). Given my
it's a public struct so immutable now, right
testing, it looks like this field tracks live changes from virsh
setvcpus, so this now needs to be explicitly documented as the
current vcpu rather than the maximum, when the two differ. Which
yes
means we have another synonym:
>>- current vcpu on running guests
>
>virDomainGetVcpusFlags(,VIR_DOMAIN_VCPU_ACTIVE)
>virDomainGetVcpus() + parsing pinning info
virDomainGetInfo()
agreed,
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit
http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine
http://rpmfind.net/
http://veillard.com/ | virtualization library
http://libvirt.org/