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@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list