[Libvir] Proposal for new Libvirt functions about virtual CPUs

[michel.ponceau at bull.net]

1) Currently the NULL virDomainPtr (meaning Domain0) is only specified in 
the 3 virDomain*Memory functions (GetMax, SetMax, Set). The other 
virDomain* functions need the actual virDomainPtr for Domain0. What is the reason for this Memory-specific 
option? Is it applicable to virtual CPUs?

2) For "xm vcpu-list" equivalent function (suggested virDomainGetVcpus) I propose to return in a new structure all the information provided by 
Xen Daemon. I am trying the following addition in libvirt.h :
typedef struct _virVcpuInfo virVcpuInfo;
struct _virVcpuInfo {
    int number;                 /* virtual CPU number */
    unsigned char state;        /* 'r'=running, 'b'=blocked, 'p'=offline 
*/
    unsigned long long cpuTime; /* CPU time used, in nanoseconds */
    int cpu;                    /* last real CPU number allocated */
    char cpumap[128];           /* affinity map of real CPUs which can be 
allocated */
};
typedef virVcpuInfo *virVcpuInfoPtr;

For cpumap, the xm command displays a string "x,y-z..." more compact than 
the list of all possible CPUs "x y y+1 y+2...z..." provided by xend. But 
the routines for this reformatting are not easy, so I propose to keep the 
xend format in virCpuInfo. What is your opinion?

3) For "xm vcpu-pin" equivalent function (suggested virDomainPinVcpu) I propose a CPU list argument in same format as virCpuInfo cpumap. Do 
you agree?

Veuillez répondre à veillard at redhat.com
Pour :  michel.ponceau at bull.net
cc :    libvir-list at redhat.com 
Objet : Re: [Libvir] Proposal for a new Libvirt function: change number of virtual 
CPUs

On Fri, Jun 23, 2006 at 05:48:40PM +0200, michel.ponceau at bull.net wrote:
> For our administration, we need to dynamically reduce the number of 
virtual
> CPUs in each domain, in same way as Xen command "xm vcpu-set". It seems
> that no Libvirt function is currently provided for that purpose. I
> successfully tried some simple changes in libvirt.c an xend_internal.c,
> mainly the following:
>     snprintf(buf, sizeof(buf), "%d", vcpus);
>     return xend_op(domain->conn, domain->name, "op", "set_vcpus", 
"vcpus",
>                    buf, NULL);
> We suggest to add this new function "virDomainSetVcpus" to Libvirt.

  Hum, let's see. We expose the number of virtual CPUs in the info 
structure
so yes that's something which is part of what we expose. So that would be

/**
 * virDomainSetVcpus:
 * @domain: a domain object or NULL
 * @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 and -1 in case of failure.
 */

int virDomainSetVcpus(virDomainPtr domain, unsigned int nvcpus) {
}

> I have not tried the hypervisor and xen store accesses for this 
function.
> Do you think they would be necessary?

  It would be preferable to go though Xend first at least. I don't think
xenstore is a good idea at this point. Now for the direct hypervisor, I'm
uncertain, it could be a good idea to provide redundancy over xend, I
assume it should not be hard to do that at the hypervisor level, the risk
is introducing incoherence between what xend thinks and what the 
hypervisor
atually implement :-)

> I am also working on two other functions to reproduce "xm vcpu-pin" and 
"xm
> vcpu-list" from Libvirt.

  vcpu-list might be a bit subtle as an API design level. Better not 
allocate
the array in libvirt, but have the user pass an array. Also how much 
information
would you extract per CPU, just on/off ?

Daniel

-- 
Daniel Veillard      | Red Hat http://redhat.com/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20060626/22970b31/attachment-0001.htm>