July 2006 - Devel - libvirt List Archives

Réf. : Re: [Libvir] Re: Proposal : add 3 functions to Libvirt API, for virtual CPUs
by jean-paul.pigache＠bull.net 31 Jul '06

31 Jul '06

I hope I will find a way to post the patches prepared by Michel Ponceau before the end of the week. Jean-Paul "Daniel P. Berrange" <berrange(a)redhat.com> Envoyé par : libvir-list-bounces(a)redhat.com 29/07/2006 09:35 Veuillez répondre à "Daniel P. Berrange" Pour : Jim Fehlig <jfehlig(a)novell.com> cc : libvir-list(a)redhat.com Objet : Re: [Libvir] Re: Proposal : add 3 functions to Libvirt API, for virtual CPUs On Fri, Jul 28, 2006 at 03:18:17PM -0600, Jim Fehlig wrote: > Has any progress been made on this proposal? I don't see anything in > current CVS. This functionality would be useful for Xen-CIM project. IIRC Michel Ponceau might have started on some prototype code, but he didn't post it to the list yet & is apparently on vacation for another couple of weeks (according to his email auto-responder). If no one else has started work on it in the meantime, I'm planning to get working on it when I return from vacation Aug 4th since I also need it for the virt-manager application. Regards, Dan. > michel.ponceau(a)bull.net wrote: > > > >Corrections on proposal: > >1) PinVcpus > >Replace: > > * @cpumap: pointer to a bit map of real CPUs (format in virVcpuInfo) > >* @maplen: length of cpumap, in 8-bit bytes > >by: > > * @cpumap: pointer to a bit map of real CPUs (in 8-bit bytes). > > * 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. > > * @maplen: number of bytes in cpumap, from 1 up to size of CPU map in > > * underlying virtualization system (Xen...). > > * If maplen < size, missing bytes are set to zero. > > * If maplen > size, failure code is returned. > > > >2) GetVcpu > >Add 4rth argument: > > * @maplen: number of bytes in cpumap field of virVcpuInfo > >virDomainGetVcpus(virDomainPtr domain, virVcpuInfoPtr info, int > >maxinfo, int maplen) > > > >3) Structure VcpuInfo > >Suppress: #define VIR_MAX_CPUS 256 > >Replace: > > unsigned char cpumap[VIR_MAX_CPUS/8]; /* Bit map of usable real CPUs. > >by: > > unsigned char cpumap[]; /* Bit map of usable real CPUs. > > Variable length: it may be less or greater than size of CPU > >map in > > underlying virtualization system (Xen...). > > > >4) Accessor macros: to be defined later. > > > >Veuillez répondre à veillard(a)redhat.com > > > >Pour : michel.ponceau(a)bull.net > >cc : libvir-list(a)redhat.com > >Objet : Re: Proposal : add 3 functions to Libvirt API, for > >virtual CPUs > > > >On Fri, Jun 30, 2006 at 04:00:45PM +0200, michel.ponceau(a)bull.net wrote: > >> 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) > > > > okay > > > >> /** > >> * 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) > > > > Can you explain more clearly what is the format of cpumap ? An example > >would be welcome, and that would be needed for the doc and maybe testing. > >What would happen if maplen is < or > than the number of CPU divided > >by 8 ? > > > >> /** > >> * 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) > > > > Hum ... now the problem with that API entry point is that we 'burn' the > >maximum 256 processors in the ABI, i.e. if we ever need to go past 256 > >client and servers need to be recompiled. Maybe this is not a real problem > >in practice but that's annoying. Is there existing APIs doing this kind > >of things (in POSIX for example), and what hard limit did they use ? > > Maybe > > int virDomainGetVcpusNr(virDomainPtr domain, int nr, virVcpuInfoPtr info, > > int maxCPU); > >Where the maxCPU is defined by the client as the number of real CPU > >it defined in its virVcpuInfoPtr and then an iteration over the virtual > >CPU defined in the domain is possible too. > >Of course if the domain uses many virtual CPUs this would become expensive > >but somehow I don't see that being the common use, I would rather guess > >the domains created use a few CPUs even if instantiated on a very > >large machine. > >This > > > > > >> with the following structure (in libvirt.h): > >> /** > >> * virVcpuInfo: structure for information about a virtual CPU in a > >domain. > >> */ > >> #define VIR_MAX_CPUS 256 > > > > Hum, there is already NUMA machines with more than 256 processors, > >it's annoying to define an API limit when you know it is already > >breakable. > > > >> 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; > > > > Hum, maybe some accessors should be provided in the API, letting the > >client > >code handle access and having to take care of indianness issues > >doesn't feel > >very nice. Something like the FD_CLR/FD_ISSET/FD_SET/FD_ZERO equivalents > >when using the select() POSIx call. > > > >> 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. > > > >Maybe that operation requires more than one hypervisor call to > >actually enable > >the processors. The simpler would be to look at the code in xend about > >what's > >needed there, maybe the kernel need to be made aware of that and I > >would expect > >this to be a xenstore operation. > >At least we know we can fallback to xend if the hypervisor call > >doesn't work > >directly. > >I don't know if virDomainGetVcpus should really be mutated into > >virDomainGetVcpusNr, I would certainly like to be able to keep that API > >extensible for more than 256 CPUs. Maybe I'm just too cautious there, > > > > I would really like feedback from others on this issue ! > >In the meantime sending the current set of patches you developped could > >allow to look closely at the 2 calls that I feel okay with. > > > > thanks and sorry it took so long ! > > > >Daniel > > > >-- > >Daniel Veillard | Red Hat http://redhat.com/ > >veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ > >http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ > > > >------------------------------------------------------------------------ > > > >-- > >Libvir-list mailing list > >Libvir-list(a)redhat.com > >https://www.redhat.com/mailman/listinfo/libvir-list > > > > -- > Libvir-list mailing list > Libvir-list(a)redhat.com > https://www.redhat.com/mailman/listinfo/libvir-list -- |=- 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 -=| -- Libvir-list mailing list Libvir-list(a)redhat.com https://www.redhat.com/mailman/listinfo/libvir-list

1 0

[Libvir] Re: Proposal : add 3 functions to Libvirt API, for virtual CPUs
by michel.ponceau＠bull.net 29 Jul '06

29 Jul '06

Corrections on proposal: 1) PinVcpus Replace: * @cpumap: pointer to a bit map of real CPUs (format in virVcpuInfo) * @maplen: length of cpumap, in 8-bit bytes by: * @cpumap: pointer to a bit map of real CPUs (in 8-bit bytes). * 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. * @maplen: number of bytes in cpumap, from 1 up to size of CPU map in * underlying virtualization system (Xen...). * If maplen < size, missing bytes are set to zero. * If maplen > size, failure code is returned. 2) GetVcpu Add 4rth argument: * @maplen: number of bytes in cpumap field of virVcpuInfo virDomainGetVcpus(virDomainPtr domain, virVcpuInfoPtr info, int maxinfo, int maplen) 3) Structure VcpuInfo Suppress: #define VIR_MAX_CPUS 256 Replace: unsigned char cpumap[VIR_MAX_CPUS/8]; /* Bit map of usable real CPUs. by: unsigned char cpumap[]; /* Bit map of usable real CPUs. Variable length: it may be less or greater than size of CPU map in underlying virtualization system (Xen...). 4) Accessor macros: to be defined later. Veuillez répondre à veillard(a)redhat.com Pour : michel.ponceau(a)bull.net cc : libvir-list(a)redhat.com Objet : Re: Proposal : add 3 functions to Libvirt API, for virtual CPUs On Fri, Jun 30, 2006 at 04:00:45PM +0200, michel.ponceau(a)bull.net wrote: > 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) okay > /** > * 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) Can you explain more clearly what is the format of cpumap ? An example would be welcome, and that would be needed for the doc and maybe testing. What would happen if maplen is < or > than the number of CPU divided by 8 ? > /** > * 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) Hum ... now the problem with that API entry point is that we 'burn' the maximum 256 processors in the ABI, i.e. if we ever need to go past 256 client and servers need to be recompiled. Maybe this is not a real problem in practice but that's annoying. Is there existing APIs doing this kind of things (in POSIX for example), and what hard limit did they use ? Maybe int virDomainGetVcpusNr(virDomainPtr domain, int nr, virVcpuInfoPtr info, int maxCPU); Where the maxCPU is defined by the client as the number of real CPU it defined in its virVcpuInfoPtr and then an iteration over the virtual CPU defined in the domain is possible too. Of course if the domain uses many virtual CPUs this would become expensive but somehow I don't see that being the common use, I would rather guess the domains created use a few CPUs even if instantiated on a very large machine. This > with the following structure (in libvirt.h): > /** > * virVcpuInfo: structure for information about a virtual CPU in a domain. > */ > #define VIR_MAX_CPUS 256 Hum, there is already NUMA machines with more than 256 processors, it's annoying to define an API limit when you know it is already breakable. > 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; Hum, maybe some accessors should be provided in the API, letting the client code handle access and having to take care of indianness issues doesn't feel very nice. Something like the FD_CLR/FD_ISSET/FD_SET/FD_ZERO equivalents when using the select() POSIx call. > 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. Maybe that operation requires more than one hypervisor call to actually enable the processors. The simpler would be to look at the code in xend about what's needed there, maybe the kernel need to be made aware of that and I would expect this to be a xenstore operation. At least we know we can fallback to xend if the hypervisor call doesn't work directly. I don't know if virDomainGetVcpus should really be mutated into virDomainGetVcpusNr, I would certainly like to be able to keep that API extensible for more than 256 CPUs. Maybe I'm just too cautious there, I would really like feedback from others on this issue ! In the meantime sending the current set of patches you developped could allow to look closely at the 2 calls that I feel okay with. thanks and sorry it took so long ! Daniel -- Daniel Veillard | Red Hat http://redhat.com/ veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

4 6

[Libvir] Source repository
by Diwaker Gupta 23 Jul '06

23 Jul '06

Given that most Xen related stuff (including virt-man) lives in Mercurial repositories, it seems a little weird (and a little cumbersome) that libvirt continues to use CVS. This issue briefly came up on the list once earlier, but didn't go anywhere. Is there any strong reason why libvirt can't move to Mercurial? Diwaker -- Web/Blog/Gallery: http://floatingsun.net/blog

3 4

Réf. : Re: [Libvir] Re: Proposal : add 3 functions to Libvirt API, for virtual CPUs
by jean-paul.pigache＠bull.net 21 Jul '06

21 Jul '06

This interesting thread is temporarilu suspended because Michel has left for some (long) vacation until August 15th. I think the last proposal is a good one and deserves to be implemented and tested. I am confident that Michel will be willing to update its patch accordingly when he comes back. Is it OK for you ?. Side question: is there a defined "sign-off" procedure to follow when submitting patches ? Cordialement. Jean-Paul Daniel Veillard <veillard(a)redhat.com> Envoyé par : libvir-list-bounces(a)redhat.com 17/07/2006 15:08 Veuillez répondre à veillard Pour : "Daniel P. Berrange" <berrange(a)redhat.com> cc : libvir-list(a)redhat.com, michel.ponceau(a)bull.net Objet : Re: [Libvir] Re: Proposal : add 3 functions to Libvirt API, for virtual CPUs On Mon, Jul 17, 2006 at 01:50:25PM +0100, Daniel P. Berrange wrote: > On Tue, Jul 11, 2006 at 10:50:53AM -0400, Daniel Veillard wrote: > > We still have a relatively simple API for the common case, and for special > > cases we have an extension capability with relatively clear definitions. it's > > a bitstrange but I think that should cover most case as best as possible > > I dont particularly like this as an API because I think it will be error > prone for application developers. Most app developers will only ever have > a handful of CPUs in their test machines, so they'll never the alternate > codepath for > 256 cpu case. Likewise I don't like the idea of a virVcpuInfo > struct which has a variable size because it will totally confuse people who > haven't read the API docs very carefully, again leading to obscure bugs. > > The root problem is that we have two conflicting goals here > > 1. Want to have virVcpuInfo be a fixed size struct > 2. We want a cpumap of arbitrary size Right this is confusing, I wanted to avoid another allocation in the general case but this made things even more confusing. > The obvious solution to this problem is to *remove* the cpumap data from > the virVcpuInfo structure completely, and always pass in a separately > malloc'd array of the correct size. So I'd suggest: > > 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 */ > } > > virDomainGetVcpus(virDomainPtr domain, virVcpuInfoPtr info, int maxinfo, > char *cpumap, int maplen); Agreed, this is the most logical approach > > The client applications calling this API already have to malloc() the memory > region for the 'info' parameter of a correct size, so having to also malloc > the cpumap parameter is no extra trouble. > > virDomainInfo info; > virDomainVpuInfoPtr cpuInfo; > int cpuMapLen; > char *cpuMap; > > virDomainGetInfo(domain, &info); > > cpuInfo = malloc(sizeof(virDomainVcpuInfo)*info.nrVirtCpu); > cpuMapLen = (info.nrVirtCpu + 7) / 8 ; > cpuMap = malloc(cpuMapLen); > > virDomainGetVCpus(domain, cpuInfo, info.nrVirtCpu, cpuMap, cpuMapLen); > > ... do stuff with the data ... > > free(cpuInfo); > free(cpuMap); > > > So you can see there is minimal extra work to always pass in cpuMap as > a separate parameter. If an application didn't care about the cpuMap > data they could simply pass in NULL. Agree. We should keep an example of use (like above completed) in the source tree to help developpers. Daniel -- Daniel Veillard | Red Hat http://redhat.com/ veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ -- Libvir-list mailing list Libvir-list(a)redhat.com https://www.redhat.com/mailman/listinfo/libvir-list

2 1

[Libvir] Bug with libvirt in Xen 3.0.1?
by pvetere＠redhat.com 21 Jul '06

21 Jul '06

Hi, I think I may have found a bug in libvirt and wanted see what people thought. I'm using the stock FC5 installation at the moment (with xen 3.0.1), and the newest version of libvirt. I am noticing that with xen 3.0.1 and newer versions of libvirt, getDomainsID() seems to return bogus values. For example: [root@test05 ~]# virsh list Id Name State ---------------------------------- 0 Domain-0 running libvir: Xen Daemon error : GET operation failed: No such domain 65486 libvir: Xen Daemon error : GET operation failed: No such domain 2986 But, if I use xm, I get what I expect: [root@test05 ~]# xm list Name ID Mem(MiB) VCPUs State Time(s) Domain-0 0 1507 2 r----- 387.5 vm1 1 256 1 -b---- 151.3 vm2 2 256 1 -b---- 87.9 After some digging around in the code, I believe that libvirt is incorrectly identifying the hypervisor as being "old" in xen_internal.c:xenHypervisorInit, and is therefore passing the incorrect parameter structure into the hypervisor when it makes its ioctl in xen_internal.c:xenHypervisorListDomains. I've tried this same test on a system running xen 3.0.2, and as I expected everything works fine. So, there must be something different about xen 3.0.1 that libvirt is not accounting for. At this point, I don't really have more time to dig further but I thought I'd bring up the issue in case someone on this list can offer more insight. Pete

3 5

[Libvir] Virtual Machine Manager 0.1.5 release
by Daniel P. Berrange 20 Jul '06

20 Jul '06

I've just pushed out another snapshot of the Virtual Machine Manager GUI application for managing Xen machines via libvirt. A summary of the changes in this 0.1.5 release[1]: * Integration with GNOME keyring for the VNC console to avoid need to remember passwords when accessing the guest domain's console * Use cairo to render a '50% alpha gray wash' over the screenshot to give appearance of a 'dimmed' display when paused. Also render the word 'paused' in big letters. * Initial cut of code for saving & restoring domain snapshots to disk * Added icons for buttons which were missing graphics * Miscellaneous RPM spec file fixes to comply with rpmlint * Update status icons to match those in the gnome-applet-vm * Added domain ID and # VCPUs to summary view * Misc bug fixes The next priority target for development is some UI for creating new VM instances (a GUI equivalent of xenguest-install.py script shipping with current Fedora Xen packages) and implenenting the UI for editing domain configuration / hardware. In addition there is now a more permanent home for the application's web pages: http://virt-manager.et.redhat.com/index.html And the Mercurial repository is now published for anonymous read-only access at: http://hg.et.redhat.com/virt/applications/virt-manager--devel Patches are welcome either as traditional unified diffs, or as mercurial changeset bundles - see the following page for details on exporting bundles using hg: http://virt-manager.et.redhat.com/scmrepo.html Regards, Dan. [1] There was a 0.1.4 but it had a fatal flaw in it breaking the console -- |=- 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 -=|

1 0

[Libvir] Question about XML
by Juan Walker 20 Jul '06

20 Jul '06

Hi, I have a question regarding the XML format that libvir uses for domain configuration. I was wondering if there is a way to use the configuration format that xm uses or if a tool exists to convert to XML. I'm writing an app to help users manage their Xen domains but I'm hoping to be able to use any .sxp files that the user already has. I suspect I missed something in the documentation about why the XML format is better, but if there is no such tool maybe I should volunteer to write one? Thanks.

3 2

[Libvir] just a question about libvirt evolution
by Philippe Berthault 20 Jul '06

20 Jul '06

Hello, Several major modifications will appear this year in future Xen releases (3.0.3 and 3.0.4) that may have impacts on libvirt. These modifications (see xen roadmap edited by Ian Pratt in july 2006) are : - Introduction of XML-RPC, - Xen configuration files in XML format, - Suppression of S-Expressions, - etc.. What is the libvirt position about these points ? Is the initial goal of libvirt to mask Xen evolutions will be always possible ? The most problematic problem would be the configurations files in XML format. Libvirt already supports its own XML format of configuration files. It seems to me that it would be interesting to use the same XML format (or a compatible format) in libvirt and in Xen. Is there a plan in this direction ? Thanks.

3 2

[Libvir] Patch to correct spelling
by Daniel P. Berrange 20 Jul '06

20 Jul '06

The attached patch changes 'informations' to 'information' throughout the codebase to fix up the English grammer. I assume its ok to commit ? 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 -=|

2 2

[Libvir] possible bug in virDomainLookupByID
by Bryan D. Payne 19 Jul '06

19 Jul '06

I'm experiencing an odd problem in virDomainLookupByID when using 0.1.3 that does not exist when using 0.1.1. Perhaps this is a side effect of switching the backend connection? I'm curious is anyone else has seen this and/or if you have any suggestions for fixing it. The attached code generates the problem that I'm seeing. Specifically, after upgrading to 0.1.3, calling virDomainLookupByID twice results in a failure on the second call. This behavior was not seen in 0.1.1. Any thoughts? Thanks, bryan PS... This problem is seen in XenAccess. Thanks to Daniele Sgandurra for bringing it to my attention. #include <stdio.h> #include <string.h> #include <libvirt/libvirt.h> #include <libvirt/virterror.h> #include <libxml/parser.h> #include <libxml/tree.h> char *get_xml_info (int id) { virConnectPtr conn = NULL; virDomainPtr dom = NULL; char *xml_data = NULL; /* NULL means connect to local Xen hypervisor */ conn = virConnectOpenReadOnly(NULL); if (NULL == conn) { printf("ERROR: Failed to connect to hypervisor\n"); goto error_exit; } /* Find the domain of the given id */ dom = virDomainLookupByID(conn, id); if (NULL == dom) { virErrorPtr error = virConnGetLastError(conn); printf("(%d) %s\n", error->code, error->message); printf("ERROR: Failed to find Domain %d\n", id); goto error_exit; } xml_data = virDomainGetXMLDesc(dom, 0); error_exit: if (NULL!= dom) virDomainFree(dom); if (NULL!= conn) virConnectClose(conn); return xml_data; } int main () { char *xml = NULL; xml = get_xml_info(1); if (!xml){ printf("Failed on first try\n"); return 0; } free(xml); xml = get_xml_info(1); if (!xml){ printf("Failed on second try\n"); return 0; } free(xml); return 1; }

3 5

[Libvir] virDomainLookupByID problem when Root
by Daniele Sgandurra 17 Jul '06

17 Jul '06

Hi all! I've tried to compile and execute info1.c both as user and as root. As user I have no problem, but as root I get: Failed to find Domain 0 I've traced back the problem to the function: virDomainLookupByID(virConnectPtr conn, int id) at the line: path = xs_get_domain_path(conn->xshandle, (unsigned int) id); When root I get path != NULL, otherwise path==NULL; if path==NULL then the block after it is executed and everything is ok, otherwise at the end of the function name=null. (I manually changed path to NULL so that I can run it when root and it works even if info.maxMem it's different from when the program is run as a normal user: it shows -4 instead of 464896). It could be a configuration problem of mine (of Xen Store for example)? Thanks! Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com

3 3

[Libvir] announce: gnome-applet-vm-0.1.0rc1
by Karel Zak 14 Jul '06

14 Jul '06

I have just pushed out a new version of the VM Applet. The changes/features are: - D-BUS support and integration with virt-manager - console helper support for privileged operations - fixed a lot of bugs - new icons - better GUI - the applet internally supports multiple libvirt connection (in future it will be useful for monitoring remote virtual machines) Web page (with screenshot of course:-): http://people.redhat.com/kzak/gnome-applet-vm/ Please, help me found bugs and improve this application. Karel -- Karel Zak <kzak(a)redhat.com>

1 0

[Libvir] Patch: Fix for UUIDs in XML parser
by Peter Vetere 13 Jul '06

13 Jul '06

Hi all. Here's a pretty straightforward patch that fixes a bug I found where, if <uuid>...</uuid> is specified in the XML on the call createLinux, it is not propagated down to Xend. The result is an instance with a different UUID than the one requested. Pete

2 1

[Libvir] Re: Proposal : add 3 functions to Libvirt API, for virtual CPUs
by michel.ponceau＠bull.net 13 Jul '06

13 Jul '06

I imagined that each Libvirt user could choose its own MAX number of CPU. If it is not possible, at least can we reserve the extended cpumap for future development (TODO, same as NULL domain pointer) ? Veuillez répondre à veillard(a)redhat.com Pour : michel.ponceau(a)bull.net cc : libvir-list(a)redhat.com Objet : Re: Proposal : add 3 functions to Libvirt API, for virtual CPUs On Thu, Jul 13, 2006 at 01:12:47PM +0200, michel.ponceau(a)bull.net wrote: > I don't understand. Libvirt users must of course compile API and > application with the same libvirt.h, after updating the value of > VIR_MAX_CPUS when necessary. And go from first info element to next one by > (info+1), which adds sizeof(virVcpuInfo) to address, including correct > length of cpumap according to: > unsigned char cpumap[(VIR_MAX_CPUS + 7) / 8]; /* Bit map of usable > real CPUs. > For alignment constraints, compiler rounds up the sizeof(virVcpuInfo)when > needed. Well if you need to recompile the library to use a larger set of CPU you don't garantee API and ABI, by definition. And you will need to recompile the library because the structures passed between the app and the library change size, this will also likely affect the proxy since I expect vCPU informations to be provided (so communication between the library and proxy must change). There is certainly solutions to the scalability problem, but suggesting a change of header and recompilation of the whole software stack is really not one I would like to propose, it breaks basically all expectations an enterprise customer would have w.r.t. using the library. Unless I really misunderstood what you were suggesting, which is possible in that case reformulating it might be a good idea, because I really understood you want to make the MAX number of CPU a compile time setting. Daniel -- Daniel Veillard | Red Hat http://redhat.com/ veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

1 0

[Libvir] Re: Proposal : add 3 functions to Libvirt API, for virtual CPUs
by michel.ponceau＠bull.net 13 Jul '06

13 Jul '06

I don't understand. Libvirt users must of course compile API and application with the same libvirt.h, after updating the value of VIR_MAX_CPUS when necessary. And go from first info element to next one by (info+1), which adds sizeof(virVcpuInfo) to address, including correct length of cpumap according to: unsigned char cpumap[(VIR_MAX_CPUS + 7) / 8]; /* Bit map of usable real CPUs. For alignment constraints, compiler rounds up the sizeof(virVcpuInfo)when needed. Veuillez répondre à veillard(a)redhat.com Pour : michel.ponceau(a)bull.net cc : libvir-list(a)redhat.com Objet : Re: Proposal : add 3 functions to Libvirt API, for virtual CPUs On Tue, Jul 11, 2006 at 05:29:52PM +0200, michel.ponceau(a)bull.net wrote: > 2) CPU map cut into standard + extension : It would be more simple to let > each Libvirt user modify the value of VIR_MAX_CPUS in private libvirt.h. > It could be similar to the version number update, from libvirt.h.in to > libvirt.h : > #define LIBVIR_VERSION_NUMBER @LIBVIRT_VERSION_NUMBER@ No, I do think it is instead very hard. You start to get into very annoying problems from an API point of view. How do you go from the first element in the info array to the next one ? in the client it's already not nice, you must do pointer arithmetic (and I really don't want to push an API which forces that to most users), it expose potential serious problem like alignment and packing, problems between versions of compilers and tools. In a nutshell I don't want an API where one need to access an array of structure where the size of the structure is not defined by the API itself. What I suggested did that in both case, either low number of CPUs and fixed size records like you initial solutions, or high number of CPUs and you work on a two dimentional array of bytes. Daniel -- Daniel Veillard | Red Hat http://redhat.com/ veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

2 1

[Libvir] Connecting to remote hypervisors?
by Nick Devito 13 Jul '06

13 Jul '06

I might be overlooking something, but, I don't see anything on the libvirt site about it. Does libvirt support connecting to a remote hypervisor, if so, how? Thanks, Nick Devito

3 2

[Libvir] Updated snapshot of virt-manager GUI application
by Daniel P. Berrange 12 Jul '06

12 Jul '06

I have just pushed out RPM / tar.gz of a new development (alpha) snapshot of the virt-manager GUI application. The changes in this snapshot are: * Fixed DBus service activation & general brokeness * Added a display of virtual CPU count in summary view * Fixed alignment of status label in details page * Make hardware config panel resizeable * Switch detailed graph rendering to use sparkline code instead of matplotlib, removing a huge RPM dependancy chain * Switch to use filled sparkline graphs instead of outline Although I didn't increment the RPM dependancy, I strongly recommend using libvirt 0.1.3 if your host is running > 5 guest domains. This reduces the number of HTTP GETs made by an order of magnitude, improving the response time / scalability of the virt-manager refresh. 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 -=|

1 0

[Libvir] Re: Proposal : add 3 functions to Libvirt API, for virtual CPUs
by michel.ponceau＠bull.net 11 Jul '06

11 Jul '06

1) PinVcpu : I consider the size of CPU map in bytes, that is (max_nb_CPUs + 7) / 8 . 2) CPU map cut into standard + extension : It would be more simple to let each Libvirt user modify the value of VIR_MAX_CPUS in private libvirt.h. It could be similar to the version number update, from libvirt.h.in to libvirt.h : #define LIBVIR_VERSION_NUMBER @LIBVIRT_VERSION_NUMBER@ Veuillez répondre à veillard(a)redhat.com Pour : michel.ponceau(a)bull.net cc : libvir-list(a)redhat.com Objet : Re: Proposal : add 3 functions to Libvirt API, for virtual CPUs On Tue, Jul 11, 2006 at 04:14:12PM +0200, michel.ponceau(a)bull.net wrote: > Corrections on proposal: > 1) PinVcpus > Replace: > * @cpumap: pointer to a bit map of real CPUs (format in virVcpuInfo) > * @maplen: length of cpumap, in 8-bit bytes > by: > * @cpumap: pointer to a bit map of real CPUs (in 8-bit bytes). > * 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. > * @maplen: number of bytes in cpumap, from 1 up to size of CPU map in > * underlying virtualization system (Xen...). > * If maplen < size, missing bytes are set to zero. > * If maplen > size, failure code is returned. Okay, that's sensible I guess except for maplen it can go from 1 to size + 7 div 8 not up to size , right ? > 2) GetVcpu > Add 4rth argument: > * @maplen: number of bytes in cpumap field of virVcpuInfo > virDomainGetVcpus(virDomainPtr domain, virVcpuInfoPtr info, int maxinfo, > int maplen) > > 3) Structure VcpuInfo > Suppress: #define VIR_MAX_CPUS 256 > Replace: > unsigned char cpumap[VIR_MAX_CPUS/8]; /* Bit map of usable real CPUs. > by: > unsigned char cpumap[]; /* Bit map of usable real CPUs. > Variable length: it may be less or greater than size of CPU map in > underlying virtualization system (Xen...). Hum, I could see compilers righteously complaining about unsigned char cpumap[]; in a structure. Maybe we should default to 256 / 8 but allow at the API level to grow over that value. What we could do is define a default of 256 available in the structure and allow an extra parameter which could point to a larger array like the following: - restore VIR_MAX_CPUS as VIR_STD_MAX_CPUS 256 - virDomainGetVcpus(virDomainPtr domain, virVcpuInfoPtr info, int maxinfo, char *lcpumap, int lmaplen); lcpumap and lmaplen being extra arguments for very large arrays for most use case, we will fit in 256 processors, those will be respectively NULL and 0, but assuming we have more than 256 processors: + maxinfo > VIR_STD_MAX_CPUS + lcpumap points to a array of bytes, they are interpreted as an array of cpumap of ((maxinfo + 7) div 8) bytes each. So if lmaplen != ((maxinfo + 7) div 8) * maxinfo then there is an error. in that case the cpumap structures of info are not filled on return. We still have a relatively simple API for the common case, and for special cases we have an extension capability with relatively clear definitions. it's a bitstrange but I think that should cover most case as best as possible > 4) Accessor macros: to be defined later. okay, Daniel -- Daniel Veillard | Red Hat http://redhat.com/ veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

2 1

[Libvir] Release of libvirt-0.1.2
by Daniel Veillard 11 Jul '06

11 Jul '06

Available at ftp://libvirt.org/libvirt/ This release includes only a couple of things: - fix the header include problem reported last week - add a proxy based driver for read only access from non-root users In a nutshell the proxy goal is to allow monitoring from unpriviledged users by running a proxy which is a small binary running as root accepting connections from libvirt instances and implementing then using either xend RPCs or hypervisor calls. Only read-only operations are implemented i.e. it is useful for monitoring. This requires the (xend-unix-server yes) option to be set in /etc/xen/xend-config.sxp since the proxy connects to xend with the httpdu local socket, that done one can disable the xend-http-server . The proxy itself is started and stopped automatically by the library on-demand. The communication between libvirt instances and the proxy is custom, currently only synchronous operations are implemented but it should be possible to add asynchronous event passing if libvirt is extended this way. The next things I will focuse on are: the 4 unimplemented yet APIs for defined but non-running domains, the CPU extensions which have been proposed last week and the HVM (fully virtualized) Xen domain support sent by Jim Fehlig. Daniel -- Daniel Veillard | Red Hat http://redhat.com/ veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

1 1

[Libvir] Updated patch for hvm guests
by Jim Fehlig 11 Jul '06

11 Jul '06

Attached is an updated patch providing some support for HVM guests. I have tested listing info on running guests and creating guests. cdrom support for HVM guests still needs some work, as does graphics options. Guests using graphics type 'sdl' still need some work. Using type 'vnc' is functional, but you must then manually use e.g. "vncviewer localhost:<dom_id>" to view. I've also included a patch that backs out some optimizations done xend_internal.c. There is a bug in xend (from testing - I think Anthony fixed it and patch got applied to unstable) that does not close the connection after initial create op causing libvirt to block indefinitely. Backing out the optimizations allowed me to use the hvm patch on _testing branch of xen. I've included it for anyone else that may want to experiment with the hvm patch on _testing xen. Finally, the attached archive contains: 1. a sample xml input file for hvm guest, 2. corresponding s-expr sent to xend, and 3. s-expr returned from xend when getting info on the running guest. I will be on vacation and not have access to network until July 9. I will improve this work after returning. Enjoy, Jim

3 9

[Libvir] Proposal : add 3 functions to Libvirt API, for virtual CPUs
by michel.ponceau＠bull.net 10 Jul '06

10 Jul '06

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.

3 2

[Libvir] Scability / performance fix for virDomainLookupByID
by Daniel P. Berrange 10 Jul '06

10 Jul '06

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

2 5

[Libvir] support for hvm guests
by Jim Fehlig 03 Jul '06

03 Jul '06

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

6 25