[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 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


>  * 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.
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 redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

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