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