[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [RFC] Specific vcpu hot-(un)plug API proposal



On Mon, Feb 06, 2012 at 10:33:59AM -0700, Eric Blake wrote:
> On 02/06/2012 10:10 AM, Peter Krempa wrote:
> > Hypervisors are starting to support hot-(un)plugging of specific vcpus.
> > This adds more flexibility for the management tools to decide which CPU
> > should be added or removed.
> > 
> > Libvirt's API in current state does not allow to choose arbitrary vCPU
> > id's for the new vCPU's and does not support removing arbitrary vCPUs
> > either.
> > 
> > I propose a following API to enable working with specific vCPUs:
> > 
> > /**
> >  * virDomainAddVcpu:
> >  * @domain: pointer to domain object
> >  * @vcpu: ID of the vcpu socket to plug the virtual CPU to
> >  * @flags: bitwise-OR of virDomainModificationImpact
> >  *
> >  * Dynamicaly add a CPU to the domain. Attach the cpu to the ID specified
> 
> s/Dynamicaly/Dynamically/
> 
> >  * by @vcpu. Note that this call may fail if the underlying virtualization
> >  * hypervisor does not support adding cpu's with specific ID  or if maximum
> >  * number of CPUs is arbitrary limited.
> >  *
> >  * The @vcpu parameter identifies the vcpu ID the new vcpu should be
> > attached
> >  * to. If -1 is specified, the new cpu is added to the first available ID.
> 
> This can only add one vcpu at a time, along with the counterpart that
> only removes one at a time; while the current virDomainSetVcpus can both
> add and subtract an arbitrary number (well, up to the hypervisor limits)
> of vcpus at once.
> 
> I'm wondering if a better interface would be a single function that
> takes a cpu map as input, and which both hot-plugs and hot-unplugs vcpus
> until the guest matches the passed-in bitmap.  That is, something like:

The downside with such a command is in the failure scenarios. eg, if
we get 1/2 way through doing an operation and hotplug/unplug fails,
what should we do. Do we try to revert to the original config (which
might also fail), do we ignore the failure & carry on trying other
vCPUs, or do we just stop leaving the 1/2 way completed state.

If we have an API for just changing the  online/offline state of a
single vCPU at a time, then the mgmt application can make its own
decision about how to handle failure of individual vCPUs. So personally
I'd go for an API

   virDomainSetVCPUState(virDomainPtr dom, unsigned int vcpunum, int online)


> > 
> > What are your thoughts on this?
> 
> You also need to propose proper XML to represent a domain with
> particular vcpus unplugged.  Right now, <vcpu current='2'>4</vcpu> is
> hard-coded to stating that vcpu 0 and 1 are enabled, and vcpu 2 and 3
> are disabled.  But if you let me call
> 
> char map = 0x5;
> virDomainSetVcpuMap(dom, &map, 1, 0);
> 
> in order to have vcpu 0 and 2 enabled, and vcpu 1 and 3 unplugged, then
> you've got to represent that in the XML somehow.  And you may want a
> convenience counterpart method that queries the vcpu map directly,
> rather than making the user have to parse XML to see the current set of
> enabled vcpus.

Agreed, we need to cope with XML mapping, at the same time as doing this
in the XML, so that we can deal with migration / XML state  / etc


Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]