- Devel - libvirt List Archives

[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

[Libvir] Xen/libVirt GUI app: "Virtual Machine Manager"
by Daniel P. Berrange 28 Jun '06

28 Jun '06

I'm pleased to make available the code for an early *development snapshot* of a graphical application for managing virtual machines. This application is using libvirt as its backend API for managing virtual machines, while the user interface is built in Python and GTK/Glade. The application allows monitoring of guest VM resource utilization / allocation. There are basic controls for controlling the run state of guest. There is also a VNC client widget (written in pure Python!) for displaying the virtual guest framebuffer on fully-virt machines: http://people.redhat.com/berrange/virt-manager/index.html This is a very early snapshot - lots of functionality isn't hooked up yet, the error handling is mostly not there, and there are certainly plenty of bugs. It should none-the-less give a reasonable feel for the kind of direction the application will evolve in. Furthermore the website includes the UI mockups done by our user interaction designers to show some of the ideas considered in ongoing development of the application. The RPMs linked to from the website should install on both Fedora Core 5[1] and Fedora Core 6 test1. The FAQ contains a list of explicit dependancies which should facilitate people trying to get it running on non-Fedora Linux distros. Regards, Dan. [1] You'll need libvirt-0.1.1 from updates-testing -- |=- 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] just a question about virDomainLookupByName function
by Philippe Berthault 28 Jun '06

28 Jun '06

An ID may be passed to virDomainLookupByName function. In exemple: virDomainLookupByName(conn, "1") is equivalent to virDomainLookupByID(conn, 1) This functionality is very useful but isn't written in the libvirt documentation. Is this functionality will continue to exist in future versions of libvirt or not ? Thanks, Philippe Berthault.

2 1

[Libvir] Proposal for new Libvirt functions about virtual CPUs
by michel.ponceau＠bull.net 26 Jun '06

26 Jun '06

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(a)redhat.com Pour : michel.ponceau(a)bull.net cc : libvir-list(a)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(a)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(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

3 4

[Libvir] Request for changing #include directives to conform to Linux standard
by Philippe Berthault 26 Jun '06

26 Jun '06

The 'virterror.h' file has an #include directive to "libvirt.h" which isn't correct because libvirt include files are installed on a sub-directory named 'libvirt'. i.e. when libvirt is compiled with configure --script=/usr, then libvirt files are installed in /usr/include/libvirt/.* To be standard with Linux usage of include files, the correct directive in virterror.h will be: #include <libvirt/libvirt.h> instead of: #include "libvirt.h" and in C/C++ source files using libvirt, there is just to include libvirt with: #include <libvirt/libvirt.h> #include <libvirt/virterror.h> This is conform to Linux usage of include files and this permit to simplify Makefile(s) because there is no need to add option -I/usr/include/libvirt to compile sources files. Regards.

2 2

[Libvir] Proposal for a new Libvirt function: change number of virtual CPUs
by michel.ponceau＠bull.net 23 Jun '06

23 Jun '06

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. I have not tried the hypervisor and xen store accesses for this function. Do you think they would be necessary? I am also working on two other functions to reproduce "xm vcpu-pin" and "xm vcpu-list" from Libvirt.

2 1

[Libvir] libvirt documentation
by Philippe Berthault 23 Jun '06

23 Jun '06

You will find, joined with this mail, your libvirt v0.1.1 documentation in Windows CHM format which is very useful for users who have both Linux and Windows stations. Regards.

2 1

[Libvir] Release of libvir-0.1.1
by Daniel Veillard 21 Jun '06

21 Jun '06

I realized yesterday that Xen unstable changeset 10277 broke the hypervisor API on i686, which led to some interesting debugging and hopefully a clean solution for this problem. I think it is worth making a release then even if the 4 new APIs for defined but non-running domains are not complete (pending more information on Xend API changes). There is still some meat in this release. ftp://libvirt.org/libvirt/ One notable improvement is that it should be fairly simple to add support for new virtualization back-end now that the driver code has been cleaned up, the new test driver to do regression test from Daniel Berrange is a good example: * building fixes: - ncurses fallback (Jim Fehlig) - VPATH builds (Daniel P. Berrange) * driver cleanups: - new entry points - cleanup of libvirt.c (with Daniel P. Berrange) * Cope with API change introduced in Xen changeset 10277 * new test driver for regression checks (Daniel P. Berrange) * improvements: - added UUID to XML serialization - buffer usage (Karel Zak) - --connect argument to virsh (Daniel P. Berrange), * bug fixes: - uninitialized memory access in error reporting - S-Expr parsing (Jim Fehlig, Jeremy Katz) - virConnectOpen bug - remove a TODO in xs_internal.c * documentation: - Python examples (David Lutterkort) - new Perl binding URL - man page update (Karel Zak) thanks to everybody who helped with this release, with code, patches, bug reports, etc... 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] bug in the virSetErrorFunc() function
by Philippe Berthault 16 Jun '06

16 Jun '06

I've written a program based on libvirt (release 0.1.0) in which I uses the virSetErrorFunc() function to avoid messages on the screen but one message is always displayed (on stderr) and isn't trapped by the virSetErrorFunc() function. This message is "Unimplemented block at xs_internal.c:255" Thanks,

2 2