- Devel - libvirt List Archives

[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

[Libvir] State of driver backend infrastructure
by Daniel P. Berrange 14 Jun '06

14 Jun '06

I'm looking to get more of the test driver backend working, and so decided it was time to audit the state of the driver backend infrastructure. There are a couple of areas which could do with some work: * Driver specific data. The virConnect & virDomain structs have explicit fields for Xen related data: virConnect: int handle; /* internal handle used for hypercall */ struct xs_handle *xshandle; /* handle to talk to the xenstore */ virDomain: int handle; /* internal handle for the domnain ID */ One idea for resolving this is to have an array of slots, one per drivers in which drivers can store data they need. void **handles Or perhaps, to allow simple int type too void union { int num; void *ptr } *handles * Connect URIs. The 'virDomainOpen' and 'virDomainOpenReadOnly' methods have an optional parameter 'name'. The Xen drivers currently ignore this, or expect it to be NULL / the string "Xen". For sake of back-compat we'll ned to preserve existing behaviour for NULL, but we should hook up URI parsing for the XenD backend to allow non local connections to work. This gives the question of what format should the URI be for Xen domains ? Although 'http://' is the protocol XenD uses, this isn't likely a good idea, because a later VMWare driver might also use a http based protocol. So, perhaps we should use generic URIs:? xend://somehost:port/ * Driver method hookup. The libvirt.c file has alot of methods which are either not hooked up to the driver backend, or hooked up, but still have duplicated (redundant?) Xen specific calls. Here is the complete status: virGetVersion: - Hardcodes support for Xen HV. No virConnectPtr handle, so how would we call out to driver backends ? virConnectOpen - OK virConnectOpenReadOnly - OK virConnectClose: - Does not call out to driver backends, simply free's struct virConnectGetType: - Does not call out to driver backends, hardcodes Xen HV virConnectGetVersion - Does not call out to driver backends, hardcodes Xen HV virConnectListDomains - Calls out to drivers, but also has duplicated code for XenD & XenStore virConnectNumOfDomains - Calls out to drivers, but also has duplicated code for XenD & XenStore virDomainCreateLinux - Does not call out to driver backends, hardcodes XenD virDomainLookupByID - Calls out to drivers, but also has duplicated code for XenD & XenStore virDomainLookupByUUID - Calls out to drivers, but also has duplicated code for XenD & XenStore virDomainLookupByUUIDString - OK (but delegates to virDomainLookupByUUID) virDomainLookupByName - Calls out to drivers, but also has duplicated code for XenD & XenStore virDomainDestroy - Does not call out to driver backends, hardcodes XenD & Xen HV virDomainFree - Does not call out to driver backends, simply free's struct virDomainSuspend - Does not call out to driver backends, hardcodes XenD & Xen HV virDomainResume - Does not call out to driver backends, hardcodes XenD & Xen HV virDomainSave - Does not call out to driver backends, hardcodes XenD virDomainRestore - Does not call out to driver backends, hardcodes XenD virDomainShutdown - Does not call out to driver backends, hardcodes XenD virDomainReboot - Does not call out to driver backends, hardcodes XenD virDomainGetName - OK virDomainGetUUID - Does not call out to driver backends, hardcodes XenD virDomainGetUUIDString - OK (but delegates to virDomainGetUUID) virDomainGetOSType - Does not call out to driver backends, calls function in XenStore driver virDomainGetMaxMemory - Does not call out to driver backends, hardcodes XenD, Xen HV, XenStore virDomainSetMaxMemory - OK virDomainSetMemory - OK virDomainGetInfo - Calls out to drivers, but also has duplicated code for XenD & XenStore virDomainGetXMLDesc - Does not call out to driver backends, hardcodes XenD virNodeGetInfo - OK virDomainDefineXML - OK virDomainUndefineXML - OK virDomainListDefinedDomains - No implemented virDomainCreate - No implemented My immediate needs for testing, are to hook up more of the methods which aren't connected to the driver backends. 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 -=|

3 6

[Libvir] A question about libvirt usage
by Philippe Berthault 13 Jun '06

13 Jun '06

Is there a notion of session in libvirt ? In other words, is it possible, between virConnectOpen() and virConnectClose(), that some Xen domains will be started, stopped, destroyed, etc.. by another operator using the xm command ou by another binary command based on libvirt. If the response is yes, is it possible to introduce a global lock in Xen (or in libvirt ?) to avoid conflict between libvirt and xm command or between several libvirt based commands. Thanks, Philippe Berthault.

2 1

[Libvir] Patch to 'ping' XenD when opening connection
by Daniel P. Berrange 13 Jun '06

13 Jun '06

Currently the XenD driver's implementation of the 'open' method will return success, regardless of whether XenD is even present. The attached patch makes the open method do a 'ping' to see if XenD is actually there, returning failure if it is not. This ensures that the XenD driver backend doesn't get activated when connecting to alternate non-Xen backends, such as the test backend I committed last week. The current 'ping' is simply to call the xenDaemonGetVersion() method since that's a pretty simle & low-overhead way to testing livliness of XenD. Any suggestions for a better ping - if not I'll go ahead & commit this change 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 3

[Libvir] A 'mock' driver enabling application unit testing
by Daniel P. Berrange 06 Jun '06

06 Jun '06

The attached patch adds a new driver which provides a 'mock' hypervisor connection. The idea behind this is to provide a completely predictable and isolated hypervisor implementation, which will facilitate creation of unit tests in applications using libvirt. The code attached is not a complete implementation, providing support only for connecting, listing domains, getting a domain by id/uuid/name, getting domain info, getting node info. Further work will hook up methods for creating domains, exporting XML & the other various libvirt APIs. The driver is intended to operate as a black box, closed system - the only interaction an application will have is via the libVirt entry points. It starts off with a single domain present, and fixed node info, and updates domain CPU time based on elapsed wall clock time. When the domain create API is hooked up this will let apps create new dummy domains within the context of the process. As I said, I delibrately implemented this driver to only have process local state. When the process shuts down all state is discarded. This keeps application usage very simple. Longer term I think it would be useful to have a 2nd, dynamic, which would allow fault injection, cross-process interaction & more to allow advanced scripting of a test scenario. I don't have time to create such a driver myself though, so I stuck with the simplest possible impl which will allow 95% of application unit testing needs to be satisfied. To use this driver, simply pass 'TestSimple' as the name parameter to virConnectOpen / virConnectOpenReadonly instead of NULL. If you are using 'virsh' then my previous patch will let you call 'virsh --connect TestSimple' I've also tested this with the 'gnome-vm-applet' panel applet. The only problem I have found is that the 'xend_internal.c' driver will always return success from its 'xenDaemonOpen' method, regardless of whether there is actually a Xen Daemon present. So when using the test driver, every method will first try to ue the XenD driver impl, fail (printing an error message) and then go onto use the test driver. The xenDaemonOpen method really needs to be fixed to only succeed when Xen is actually present. Or perhaps it should only try to run when the 'name' passed to virConnectOpen is NULL or 'Xen' - ie be a no op if the name is 'TestSimple' / QEMU / any other driver implementation. I'm not sure whether we want to commit this to the libvirt codebae just, since there is a fair bit more work to be done to hook up additional methods. 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 4