[libvirt] [RFC] Specific vcpu hot-(un)plug API proposal
Eric Blake
eblake at redhat.com
Mon Feb 6 17:33:59 UTC 2012
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:
/**
* virDomainSetVcpuMap:
* @domain: pointer to domain object
* @vcpumap: pointer to bit map of vcpus to enable. Each bit set to
* 1 means the vcpu is plugged in. Bytes are stored in
* little-endian order: VCPU0-7, 8-15..., with lowest vcpu
* number in least significant bit.
* @maplen: number of bytes in vcpumap
* @flags: bitwise-OR of virDomainModificationImpact
*
* Dynamically alter the set of vcpus enabled in a domain. Some
* hypervisors only support hot-plug, rather than hot-unplug.
*
* @vcpumap must contain at least 1 set bit. If @maplen is
* shorter than the hypervisor maximum, unspecified bytes are
* treated as clear. Attempts to enable a vcpu beyond the
* current maximum vcpu of the domain will fail; raise the
* maximum first, by using virDomainSetVcpusFlags().
*
* @flags controls whether the change is to a running domain,
* configuration for next boot of a persistent domain, or both.
*/
int
virDomainSetVcpuMap(virDomainPtr domain,
unsigned char *vcpumap, int maplen, unsigned int flags)
>
> 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.
--
Eric Blake eblake at redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 620 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20120206/3f73806e/attachment-0001.sig>
More information about the libvir-list
mailing list