[Libvir] Proposal : add 3 functions to Libvirt API, for virtual CPUs
by michel.ponceau＠bull.net
For our administration, we need the following actions, while concerned
domain is running:
1) Change the number of virtual CPUs.
2) Change the pinning (affinity) of a virtual CPU on real CPUs.
3) Get detailed information for each virtual CPU.
Currently there is no Libvirt function provided for that. We suggest to
add the following 3 functions (in libvirt.c):
/**
* virDomainSetVcpus:
* @domain: pointer to domain object, or NULL for Domain0
* @nvcpus: the new number of virtual CPUs for this domain
*
* Dynamically change the number of virtual CPUs used by the domain.
* Note that this call may fail if the underlying virtualization
hypervisor
* does not support it or if growing the number is arbitrary limited.
* This function requires priviledged access to the hypervisor.
*
* Returns 0 in case of success, -1 in case of failure.
*/
int virDomainSetVcpus(virDomainPtr domain, unsigned int nvcpus)
/**
* virDomainPinVcpu:
* @domain: pointer to domain object, or NULL for Domain0
* @vcpu: virtual CPU number
* @cpumap: pointer to a bit map of real CPUs (format in virVcpuInfo)
* @maplen: length of cpumap, in 8-bit bytes
*
* Dynamically change the real CPUs which can be allocated to a virtual
CPU.
* This function requires priviledged access to the hypervisor.
*
* Returns 0 in case of success, -1 in case of failure.
*/
int virDomainPinVcpu(virDomainPtr domain, unsigned int vcpu,
unsigned char *cpumap, int maplen)
/**
* virDomainGetVcpus:
* @domain: pointer to domain object, or NULL for Domain0
* @info: pointer to an array of virVcpuInfo structures
* @maxinfo: number of structures in info array
*
* Extract information about virtual CPUs of a domain, store it in info
array.
*
* Returns the number of info filled in case of success, -1 in case of
failure.
*/
int virDomainGetVcpus(virDomainPtr domain, virVcpuInfoPtr info, int
maxinfo)
with the following structure (in libvirt.h):
/**
* virVcpuInfo: structure for information about a virtual CPU in a domain.
*/
#define VIR_MAX_CPUS 256
typedef enum {
VIR_VCPU_OFFLINE = 0, /* the virtual CPU is offline */
VIR_VCPU_RUNNING = 1, /* the virtual CPU is running */
VIR_VCPU_BLOCKED = 2, /* the virtual CPU is blocked on resource
*/
} virVcpuState;
typedef struct _virVcpuInfo virVcpuInfo;
struct _virVcpuInfo {
unsigned int number; /* virtual CPU number */
int state; /* value from virVcpuState */
unsigned long long cpuTime; /* CPU time used, in nanoseconds */
int cpu; /* real CPU number, or -1 if offline */
unsigned char cpumap[VIR_MAX_CPUS/8]; /* Bit map of usable real CPUs.
Each bit set to 1 means that corresponding CPU is usable.
Bytes are stored in little-endian order: CPU0-7, 8-15...
In each byte, lowest CPU number is least significant bit
*/
};
typedef virVcpuInfo *virVcpuInfoPtr;
I have successfully tried those functions via Xen hypervisor, except for
the first (SetVcpus) where hypervisor operation DOM0_MAX_VCPUS fails
(maybe it is not possible on a running domain ?). That function was
successful via Xen daemon.
18 years, 4 months
- 3
- 2
[Libvir] Scability / performance fix for virDomainLookupByID
by Daniel P. Berrange
Attached is a patch to significantly increase scalability / performance of
the xenDaemonLookupByID method. The current implementation would get a
list of all domain names from XenD, and then iterate doing a HTTP GET on
/xend/domain/[name] until the domain with match ID was found. THis had
O(n) complexity, with the result that when running on a system with 20
actives domains, 'virsh list' would have O(n^2) complexity needing ~230
HTTP calls, giving a runtime of ~9 seconds.
The patch is to make the code do a HTTP GET on /xend/domain/[id] which we
just discovered is a valid URL to access. This makes the method call O(1),
and 'virsh list' is now a saner O(n), and completes in ~1 second. While
still not great performance, this is certainly much better. I think it
ought to be possible to optimize the code still further so that XenD is
avoided altogether for simple commands which can be fullfilled purely
with data available from Hypervisor, but that will need further
investigation.
Please review the patch in case I missed any bugs / edge cases
Regards,
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
18 years, 4 months
- 2
- 5
[Libvir] support for hvm guests
by Jim Fehlig
Daniel,
FYI, I'm working on a patch to support hvm guests. Attached is the work
thus far. Calling "virsh dumpxml some_hvm_guest" will (almost)
correctly dump xml config info on hvm guests. Needs to handle
"type=ioemu" component of VIF specification. Currently in the XML there
is a type attribute for the interface element that specifies bridge,
route, etc. How would you like to structure the interface element and
its children to account for hvm guests?
Using "virsh create file" where file contains XML config for hvm guests
may be close to working but I haven't tested it yet. There are several
options that need to be added to the XML to support hvm guests. If we
can agree on the structure I can add the functionality.
Regards,
Jim
18 years, 4 months
- 6
- 25