On 03/04/2013 03:19 PM, Laszlo Ersek wrote: > Signed-off-by: Laszlo Ersek <ler...@redhat.com> > ---
> +# @guest-set-vcpus: > +# > +# Attempt to reconfigure (currently: enable/disable) logical processors > inside > +# the guest. > +# > +# The input list is processed node by node in order. In each node @logical-id > +# is used to look up the guest VCPU, for which @online specifies the > requested > +# state. The set of distinct @logical-id's is only required to be a subset of > +# guest-supported identifiers. There's no restriction on list length or on > +# repeating the same @logical-id (with possibly different @online field). > +# Preferably the input list should describe a modified subset of > +# @guest-get-vcpus' return value. > +# > +# If part or whole of the requested operation can't be carried out, the guest > +# VCPU state will be unspecified. Completely unspecified? Or is it guaranteed that a subsequent successful guest-get-vcpus will still be reliably to learn after the fact what happened? Would it make any more sense to have only a guest-set-vcpu, which attempts to set the state of a single vcpu, instead of an open-ended array of successive vcpu modifications in guest-set-vcpus? The interface seems relatively sane, though, and it looks like something that libvirt would be able to use without having to add any new APIs (just a new flag value to the existing virDomainSetVcpusFlags() function). -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
