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

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

 



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

Attachment: signature.asc
Description: OpenPGP digital signature

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]