- Devel - libvirt List Archives

[Libvir] Release of libvirt-0.3.0
by Daniel Veillard 09 Jul '07

09 Jul '07

Considering the amount of changes available in CVS, a release was in order plus increasing the minor release number was also making sense. The package is available at ftp://libvirt.org/libvirt/ The main change is the secure remote support at the API level thanks to Richard Jones, look at the specific page to get informations on what is available and how to set up the certificates needed for authentication: http://libvirt.org/remote.html it's worth also looking at the URI documentation to see how to build the connection URI strings http://libvirt.org/uri.html Last thing, the background daemon has been renamed between versions 0.2.3 and the current version from libvirt_qemud to libvirtd since it now also serve for the remote support, so when upgrading the package it's a good idea to stop first the libvirt service, do the upgrade and then restart the service otherwise you may end up with a old version of the daemon running. This release includes a lot of changes: + Secure Remote support (Richard Jones). See the remote page of the documentation + Documentation: - remote support (Richard Jones) - description of the URI connection strings (Richard Jones) - update of virsh man page - matrix of libvirt API/hypervisor support with version informations (Richard Jones) + Bug fixes: - examples Makefile.am generation (Richard Jones) - SetMem fix (Mark Johnson) - URI handling and ordering of drivers (Daniel Berrange) - fix virsh help without hypervisor (Richard Jones) - id marshalling fix (Daniel Berrange) - fix virConnectGetMaxVcpus on remote (Richard Jones) - avoid a realloc leak (Jim Meyering) - scheduler parameters handling for Xen (Richard Jones) - various early remote bug fixes (Richard Jones) - remove virsh leaks of domains references (Masayuki Sunou) - configCache refill bug (Richard Jones) - fix XML serialization bugs + Improvements: - QEmu switch to XDR-based protocol (Dan Berrange) - device attach/detach commands (Masayuki Sunou) - OCaml bindings (Richard Jones) - new entry points virDomainGetConnect and virNetworkGetConnect useful for bindings (Richard Jones) - reunitifaction of remote and qemu daemon under a single libvirtd with a config file (Daniel Berrange) + Cleanups: - parsing of connection URIs (Richard Jones) - messages from virsh (Saori Fukuta) - Coverage files (Daniel Berrange) - Solaris fixes (Mark Johnson) - avoid [r]index calls (Richard Jones) - release information in Xen backend - virsh cpupin command cleanups (Masayuki Sunou) - xen:/// suppport as standard Xen URI (Richard Jones and Daniel Berrange) - improve driver selection/decline mechanism (Richard Jones) - error reporting on XML dump (Richard Jones) - Remove unused virDomainKernel structure (Richard Jones) - daemon event loop event handling (Daniel Berrange) - various unifications cleanup in the daemon merging (Daniel Berrange) - internal file and timer monitoring API (Daniel Berrange) - remove libsysfs dependancy - call brctl program directly (Daniel Berrange) - virBuffer functions cleanups (Richard Jones) - make init script LSB compliant - error handling on lookup functions (Richard Jones) - remove internal virGetDomainByID (Richard Jones) - revamp of xen subdrivers interfaces (Richard Jones) + Localization updates Thanks to everybody who helped for this release, with code, bug reports or suggestions ! Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ 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] XML escaping patch
by Daniel Veillard 06 Jul '07

06 Jul '07

This is related to bug #206653 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=206653 basically we are very optimistic when generating the XML files, and sometimes this can break. The most common case is if some string inherited from the user input or some other config file embeds one of > < or & , another one would be if the strings are containing character outside of ACSII range and not encoded in UTF-8. We can at least cope with the easy case of escaping the 3 characters. This patch adds a simple buffer printing routing working with a simple string argument, and use it for the 2 cases where I think it's most likely to be needed i.e. cmdline and bootloader_args. There is a number of places where paths are used and the user might use weird character names, but since those cases can't be handled properly (you can't change that path or try to convert encoding on the fly since we can't guess reliably which one is used) I didn't tried to change those. This makes for a relatively simple patch which should IMHO cover most case where we may break while we really should not. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

3 7

[Libvir] Some doubts for OpenVZ
by Shuveb Hussain 06 Jul '07

06 Jul '07

Hi, I have some basic doubts. 1. The OpenVZ system has one config file per VM which contains all the VM's parameters. So, during libvirt start-up, these files can be read, or openvz utils can be popened() to get information regarding these VMs. Is there a necessity to have per-vm config files in libvirt for the OpenVZ VMs? I understand UUIDs are used to identify each of the running VMs. Where will these values persist? Can I do away with UUIDs for OpenVZ and avoid the libvirt specific config file? 2. In OpenVZ, there is just a VPS ID/Name. There is no temporary reference like 'id'. For example QEMU is using the process PID. There is no such notion for OpenVZ. In that case, can I make 'name' and 'id' same for OpenVZ? Thanks, -- Shuveb Hussain Unix is very user friendly. It is just a little choosy about who its friends are http://www.binarykarma.com

3 5

[Libvir] virsh vcpupin does not work with xend
by Saori Fukuta 06 Jul '07

06 Jul '07

Hi, The virsh vcpupin command does not work when it uses Xend(xend_internal.c). HV(xen_internal.c) works fine. I'm testing on Xen3.1.0(hypervisor_version=2, dom_interface_version=5, xendConfigVersion=4), and using current libvirt(ChangeLog revision 1.546). To solve this problem, I got the xend debug information and compared that. * in the case of executing "virsh vcpupin 63 7 1" * [2007-05-29 09:33:20 4258] DEBUG (XendDomain:1297) dom(63) cpu 7 cpumap [1](<type'str'>) * in the case of executing "xm vcpu-pin 63 7 1" * [2007-05-29 09:33:32 4258] DEBUG (XendDomain:1297) dom(63) cpu 7 cpumap [1](<type'list'>) There is one different thing. The type of cpumap is str when executing virsh command, but the type of cpumap is list when executing xm command. Do you have any idea ? Thanks, Saori Fukuta

2 4

[Libvir] LSBization of libvirt init script
by Daniel Veillard 06 Jul '07

06 Jul '07

Small patch applied to qemud/libvirtd.init.in: - adds an LSB compliant header - add a couple of LSB defined functions - fixes the name in the chkconfig comments Hopefully it's correct :-) Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

2 2

[Libvir] [Q]Will virConnectNumOfNetworks and virConnectNumOfDefinedNetworks be supported by Xen ?
by S.Sakamoto 06 Jul '07

06 Jul '07

Hi, When I use virt-manager that is connected by xen, the following error is given at every monitoring. libvir: Error : this function is not supported by the hypervisor: virConnectNumOfNetworks libvir: Error : this function is not supported by the hypervisor: virConnectNumOfDefinedNetworks Therefore I have a question. Will virConnectNumOfNetworks and virConnectNumOfDefinedNetworks be supported by Xen ? When is it if supported ? Thanks, Shigeki Sakamoto.

4 8

Re: [Libvir] [RFC]OpenVZ XML def
by Richard W.M. Jones 05 Jul '07

05 Jul '07

Shuveb Hussain wrote: [...] OK, but still let us know if there are particular things which are a problem to parse. Also if you can just follow-up sometime with example output from OpenVZ commands. I'd like to see that, since I tried to get OpenVZ working on my machine, but it broke down (unrelated to OpenVZ :-) Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903

1 0

Re: [Libvir] [RFC]OpenVZ XML def
by Richard W.M. Jones 05 Jul '07

05 Jul '07

Shuveb Hussain wrote: >> >> Daemon though? Can't the libvirt code just invoke the OpenVZ commands >> directly? > > Yeah, that is very much possible. But if it were a daemon, it could be > a Python daemon, since text processing is much simpler and I don't > have to use the str*( ) funcs in C. What is your comment? I'm a big advocate of using a sane language instead of C, but libvirt is written in C for better or worse. The problem with a separate daemon is management of that daemon. Something needs to start it and stop it, it needs to have sockets with the right permissions and so on. What happens if the process runs and can't find the daemon? What is the path to the socket? etc. etc. At the moment we have two daemons - the qemu daemon (which has two separate functions intertwined), and a remote daemon (necessary, because there's no other way to communicate to a remote machine). One idea would be to have the Python code fork off from the main program and communicate over a pipe. With this, there is no daemon management problem. +----------------+ | Program | | - - - - - - - -| | libvirt | +----------------+ | | fork(2) and pipe(2) | +-------------+ | Python code | +-------------+ But I'm not the person who ultimately decides what would be acceptable in libvirt. You'd need to get general agreement on the best way to do this. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903

3 7

[Libvir] [PATCH] virDomainLookup* functions raise VIR_ERR_NO_DOMAIN if the domain doesn't exist
by Richard W.M. Jones 04 Jul '07

04 Jul '07

The patches that I'm going to follow up with change virDomainLookup* functions so that they raise VIR_ERR_NO_DOMAIN where a domain doesn't exist (but there is no other error), else raise some other error where there's an actual error occuring. This will allow wrappers in other languages to distinguish the three cases found / not found / error. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903

3 20

[Libvir] [PATCH] Fix xm_internal configCache
by Richard W.M. Jones 04 Jul '07

04 Jul '07

This patch: (1) Fixes inactive domains over remote. The real cause of this error turned out to be that after configCache hash is created, the last refresh date wasn't reset, so a subsequent call to xenXMConfigCacheRefresh might not actually repopulate the cache. This only affects the remote case, because only in the remote case do we have a long running process (libvirtd) which closes and reopens xm_internal.c, so this code had never been exercised before. It also explains why the bug was annoyingly intermittent. If you wait >= 10 seconds during testing, then the cache does get refilled, so the bug is hidden. (2) Adds error messages to xenXMConfigCacheRefresh. (3) As Daniel Veillard suggested, change the obscure !nconnections-- condition to two explicit statements. (4) In xenXMOpen, change the condition from nconnections == 0 to configCache == NULL, to remove the implicit dependency between the two variables. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903

2 2

[Libvir] [PATCH] xend 404 errors return VIR_ERR_NO_DOMAIN
by Richard W.M. Jones 04 Jul '07

04 Jul '07

(1) Check for 404 errors from xend and turn them into VIR_ERR_NO_DOMAIN (currently they are VIR_ERR_POST_FAILED). You'll typically see this when you have a handle to a domain, but the underlying domain is shutdown, as in this example: $ python Python 2.4.3 (#1, Dec 11 2006, 11:39:03) [GCC 4.1.1 20061130 (Red Hat 4.1.1-43)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import libvirt >>> conn = libvirt.open ("xen+tls:///") >>> dom = conn.lookupByName ("fc6_6") >>> dom.suspend () 0 >>> dom.resume () 0 #### here, I shut down the domain using 'xm' >>> dom.suspend () libvir: Xen Daemon error : Domain not found: No such domain fc6_6 Traceback (most recent call last): File "<stdin>", line 1, in ? File "/home/rjones/local/lib/python2.4/site-packages/libvirt.py", line 359, in suspend if ret == -1: raise libvirtError ('virDomainSuspend() failed', dom=self) libvirt.libvirtError: virDomainSuspend() failed Domain not found: No such domain fc6_6 (2) There was a case where xend was returning an error, but we didn't translate that into an error return code (-1). I'm sure this is an oversight, and the patch fixes it. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903

2 1

[Libvir] [PATCH] Fix callers to virGetDomain and virGetNetwork
by Richard W.M. Jones 04 Jul '07

04 Jul '07

(1) Removes virGetDomainByID. This function was neither used nor exported. (2) virGetDomain sets a virterror connection error whenever anything bad happens (realistically malloc failure is the only thing that can go wrong). Therefore callers do not need to set virterror if the function returns NULL. The patch fixes these callers. (3) Same as (2), for virGetNetwork. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903

2 1

[Libvir] Proposal: Python bindings should turn NO_DOMAIN/NO_NETWORK errors in KeyError exceptions
by Richard W.M. Jones 04 Jul '07

04 Jul '07

I propose that we should change the Python bindings so that when the virterror errors VIR_ERR_NO_DOMAIN and VIR_ERR_NO_NETWORK occur in the lookup* functions only, should cause KeyError to be raised. According to: http://docs.python.org/lib/module-exceptions.html "[KeyError is] raised when a mapping (dictionary) key is not found in the set of existing keys." I've already changed the OCaml bindings so that these errors get converted into Not_found exception, which is the "natural" exception for when something is looked up and not found. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903

2 2

[Libvir] [PATCH] virNetworkLookup* functions should raise VIR_ERR_NO_NETWORK
by Richard W.M. Jones 04 Jul '07

04 Jul '07

This small patch changes the virNetworkLookup* functions so that they raise VIR_ERR_NO_NETWORK in the case where the network cannot be found (as opposed to some other error). It requires the VIR_ERR_NO_DOMAIN patches (see previous thread) to be applied first, or at least patch #1 from that series. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903

2 2

[Libvir] [PATCH] Readd buffer errors & some cleanups
by Richard W.M. Jones 04 Jul '07

04 Jul '07

This readds some error checking of the returns from virBuffer* functions, removes need for is_blank (a _GNU_SOURCE extension), and a couple of other very minor cleanups. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903

3 4

[Libvir] PATCH: Fix remote driver to handle network API for local non-QEMU
by Daniel P. Berrange 04 Jul '07

04 Jul '07

The remote_internal.c code is basically a no-op in its remoteNetworkOpen method. This means the remote driver will only handle the networking APIs, if it is also handling the main domain APIs. This works fine if connecting to a remote URI, or if using QEMU URIs, but it does not work if using the test or Xen drivers. To make this work the remoteNetworkOpen method needs to open a connection to the remote daemon IIF the remoteOpen method did not already open one. So the attached patch adds the neccessary logic in remoteNetworkOpen. It also adds code to remoteNetworkClose to make it shutdown& free the connection IIF it was opened by the remoteNetworkOpen method. This is what the extra 'networkOnly' field in the 'struct private_data' is used to check. Second, all of the implementations of virNetwork* APIs in the remote_internal.c driver must use the 'struct private_data *' from networkPrivateData field in virConnectPtr, not the 'privateData' field. This is because the 'privateData' field is probably storing data related to the Xen or Test drivers. Third, this also fixes the qemu_driver.c which incorrectly used the privateData field insteadof the networkPrivateData field for 2 of the networking APIs, and finally makes sure the qemu_driver.c also acccepts the use of qemu:///session APIs for root user. 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 5

[Libvir] Proposal: libvirt should remove or rename a save file after a successful restore
by Richard W.M. Jones 02 Jul '07

02 Jul '07

Chris Lalancette found this problem: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246105 <quote> Once an "xm restore" has successfully completed, the -save file that it came from should really be deleted. Restoring a domain a second time from the same save file will result in disk corruption; the kernel VM state (in the saved file) will be in an inconsistent state with respect to what is actually on disk (in the domain disk file). The only valid use I can see for the -save file after a restore is possibly for some crash analysis, but even that could be worked around by renaming the save file after a success. In particular, I just ran into this situation (and I'm worried customers might do the same): [and then he goes on to describe a scenario in which you can commonly hit this situation] </quote> So the obvious and simple solution, it seems to me, is just to change libvirt.c:virDomainRestore so that if the driver underneath it returns from the restore without error, then we either remove or rename the restore file. It's a trivial patch -- what do people think? My thoughts: * Removing the file might seem quite abrupt/unexpected, and there is the possibility of data loss. * You have to rename the file as a hidden file (dotfile) in order for xendomains to ignore it. However these files are big and having large, hidden files which build up in number over time sounds like it could be a bad thing. * This might be considered a significant behaviour change. * It's easier to handle this for the remote case if we make the change inside libvirt, rather than in virsh etc. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903

3 2

[Libvir] Cleanup patch
by Daniel Veillard 29 Jun '07

29 Jun '07

Enclosed is a cleanup patch I applied, it corrects the XML api generation, fixes warning in the XSLT stylesheet, add comments to a number of internal functions, makes most function of the QEmu back-end static, fixes a few bugs found in the way. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

2 2

[Libvir] re: hvsupport html page
by Philippe Berthault 29 Jun '07

29 Jun '07

A great work ! This new help page will be very useful for all developers :-) Thanks a lot. P.Berthault.

1 0

[Libvir] [PATCH] Do check the UUID in __virGetDomain()
by Masayuki Sunou 29 Jun '07

29 Jun '07

Hi This patch adds checking the UUID in __virGetDomain(). Now, the UUID of domain is wrong in the following operations. 1. Start virsh in interactive mode. 2. Execute domuuid to the domain 3. Execute undefine to the domain which executed domuuid in 2. 4. Create the domain whose name is same as the domain that executed undefine. 5. Execute domuuid for the new domain This patch can fix it. Signed-off-by: Masayuki Sunou <fj1826dm(a)aa.jp.fujitsu.com> Thanks, Masayuki Sunou. -------------------------------------------------------------------------------- Index: src/hash.c =================================================================== RCS file: /data/cvs/libvirt/src/hash.c,v retrieving revision 1.22 diff -u -p -r1.22 hash.c --- src/hash.c 8 May 2007 10:53:27 -0000 1.22 +++ src/hash.c 7 Jun 2007 02:08:41 -0000 @@ -758,8 +758,14 @@ __virGetDomain(virConnectPtr conn, const ret = (virDomainPtr) virHashLookup(conn->domains, name); if (ret != NULL) { - /* TODO check the UUID */ - goto done; + if (memcmp(ret->uuid, uuid, 16)) { + if (virFreeDomain(conn, ret, 0) < 0) { + xmlMutexUnlock(conn->hashes_mux); + return(NULL); + } + } else { + goto done; + } } /* @@ -813,7 +819,7 @@ error: * Returns the reference count or -1 in case of failure. */ int -virFreeDomain(virConnectPtr conn, virDomainPtr domain) { +virFreeDomain(virConnectPtr conn, virDomainPtr domain, int lock) { int ret = 0; if ((!VIR_IS_CONNECT(conn)) || (!VIR_IS_CONNECTED_DOMAIN(domain)) || @@ -821,7 +827,8 @@ virFreeDomain(virConnectPtr conn, virDom virHashError(conn, VIR_ERR_INVALID_ARG, __FUNCTION__); return(-1); } - xmlMutexLock(conn->hashes_mux); + if (lock) + xmlMutexLock(conn->hashes_mux); /* * decrement the count for the domain @@ -853,13 +860,14 @@ virFreeDomain(virConnectPtr conn, virDom if (conn->domains != NULL) virHashFree(conn->domains, (virHashDeallocator) virDomainFreeName); - if (conn->hashes_mux != NULL) + if (conn->hashes_mux != NULL && lock) xmlFreeMutex(conn->hashes_mux); free(conn); return(0); done: - xmlMutexUnlock(conn->hashes_mux); + if (lock) + xmlMutexUnlock(conn->hashes_mux); return(ret); } Index: src/internal.h =================================================================== RCS file: /data/cvs/libvirt/src/internal.h,v retrieving revision 1.41 diff -u -p -r1.41 internal.h --- src/internal.h 8 May 2007 10:53:27 -0000 1.41 +++ src/internal.h 7 Jun 2007 02:08:41 -0000 @@ -202,7 +202,7 @@ virDomainPtr __virGetDomain (virConnectP const char *name, const unsigned char *uuid); int virFreeDomain (virConnectPtr conn, - virDomainPtr domain); + virDomainPtr domain, int lock); virDomainPtr virGetDomainByID(virConnectPtr conn, int id); virNetworkPtr __virGetNetwork (virConnectPtr conn, Index: src/libvirt.c =================================================================== RCS file: /data/cvs/libvirt/src/libvirt.c,v retrieving revision 1.73 diff -u -p -r1.73 libvirt.c --- src/libvirt.c 5 Jun 2007 12:06:08 -0000 1.73 +++ src/libvirt.c 7 Jun 2007 02:08:41 -0000 @@ -730,7 +730,7 @@ virDomainFree(virDomainPtr domain) virLibDomainError(domain, VIR_ERR_INVALID_DOMAIN, __FUNCTION__); return (-1); } - if (virFreeDomain(domain->conn, domain) < 0) + if (virFreeDomain(domain->conn, domain, 1) < 0) return (-1); return(0); } Index: src/qemu_internal.c =================================================================== RCS file: /data/cvs/libvirt/src/qemu_internal.c,v retrieving revision 1.25 diff -u -p -r1.25 qemu_internal.c --- src/qemu_internal.c 5 Jun 2007 12:06:08 -0000 1.25 +++ src/qemu_internal.c 7 Jun 2007 02:08:42 -0000 @@ -906,7 +906,7 @@ static int qemuUndefine(virDomainPtr dom } cleanup: - if (virFreeDomain(dom->conn, dom) < 0) + if (virFreeDomain(dom->conn, dom, 1) < 0) ret = -1; return ret; Index: src/xend_internal.c =================================================================== RCS file: /data/cvs/libvirt/src/xend_internal.c,v retrieving revision 1.116 diff -u -p -r1.116 xend_internal.c --- src/xend_internal.c 5 Jun 2007 12:06:09 -0000 1.116 +++ src/xend_internal.c 7 Jun 2007 02:08:42 -0000 @@ -1900,7 +1900,7 @@ error: virXendError(conn, VIR_ERR_INTERNAL_ERROR, _("failed to parse Xend domain information")); if (ret != NULL) - virFreeDomain(conn, ret); + virFreeDomain(conn, ret, 1); return(NULL); } #endif /* !PROXY */ @@ -3055,7 +3055,7 @@ xenDaemonCreateLinux(virConnectPtr conn, /* Make sure we don't leave a still-born domain around */ if (dom != NULL) { xenDaemonDomainDestroy(dom); - virFreeDomain(dom->conn, dom); + virFreeDomain(dom->conn, dom, 1); } if (name != NULL) free(name);

4 8

[Libvir] request for libvirt documentation improvement
by Philippe Berthault 29 Jun '07

29 Jun '07

The documentation of libvirt doesn't indicate which functions are for Xen or QEMU or both. The only way to know that, is by searching in libvirt sources. It would be interesting for libvirt users to add in the documentation, for each function, a mention such as "QEMU only", "Xen(TM) only", "QEMU and Xen(TM)", etc.. Regards. Libvirt 0.2.3 functions dedicated to QEMU only: virConnectListDefinedNetworks virConnectListNetworks virConnectNumOfDefinedNetworks virConnectNumOfNetworks virDomainGetAutostart virDomainSetAutostart virNetworkCreate virNetworkCreateXML virNetworkDefineXML virNetworkDestroy virNetworkFree virNetworkGetAutostart virNetworkGetBridgeName virNetworkGetName virNetworkGetUUID virNetworkGetUUIDString virNetworkGetXMLDesc virNetworkLookupByName virNetworkLookupByUUID virNetworkLookupByUUIDString virNetworkSetAutostart virNetworkUndefine Libvirt 0.2.3 functions dedicated to Xen(TM) only: virConnectGetMaxVcpus virConnectGetType virDomainAttachDevice virDomainCoreDump virDomainDetachDevice virDomainGetMaxMemory virDomainGetSchedulerParameters virDomainGetSchedulerType virDomainPinVcpu virDomainReboot virDomainSetMaxMemory virDomainSetMemory virDomainSetSchedulerParameters virDomainSetVcpus

6 10

[Libvir] Proposal: New virDomainLookup function to indicate Not found vs Error
by Richard W.M. Jones 29 Jun '07

29 Jun '07

virt-install has some code which waits for a domain to appear just after it has been created. It looks like the loop attached to the end of this email, and is functional but has two problems. Problem (1) is that self.conn.lookupByName doesn't distinguish between a "Not found" domain and an actual error. For example there is no way to tell the difference between being unable to contact xend (an actual error), and being able to contact xend, but xend not being able to find the domain (not found). As shown here: >>> import libvirt >>> conn = libvirt.open ("xen+tls:///") >>> d = conn.lookupByName ("Domain-0") >>> d = conn.lookupByName ("doesnotexist") [...] libvirt.libvirtError: virDomainLookupByName() failed then I deliberately kill the remote daemon: >>> d = conn.lookupByName ("doesnotexist") libvir: Remote error : Error in the push function. [...] The first exception is a Not found condition (not an error) whereas the second is an error. Problem (2) is that virterror is over anxious to print error messages to stderr, even if the caller can handle them and even if (as in the Not found case) they don't indicate errors. In practical terms this means that the virt-install loop attached below may print out 1 or 2 error messages even when it is functioning normally. You'll see an error like this appearing [sic]: libvir: Xen Daemon error : GET operation failed: Since it's difficult to change the LookupBy* functions without changing the ABI, I suspect that the best thing to do is going to be to add a new call with better semantics. Therefore I suggest: virDomainPtr * virDomainLookup (virConnectPtr conn, int flags, int id, char *str, int *error); where flags is one of: VIR_LOOKUP_BY_ID, VIR_LOOKUP_BY_NAME, VIR_LOOKUP_BY_UUID or VIR_LOOKUP_BY_UUID_STRING The return values are: ret = domain, *error = 0 => found it ret = NULL, *error = 0 => not found ret = NULL, *error = 1 => error (check virterror) Addition 1: There would be a similar function virNetworkLookup, but without needing the 'id' parameter because networks don't have IDs. Addition 2: Change the driver internals so that they don't call virterror in the not found case. (This requires quite a bit of rejigging in xend_internal, but is not too hard). Addition 3: Language bindings could be modified to detect this function and if present change their existing LookupBy* functions to use the new interface. Thoughts? Rich. ---------------------------------------------------- This is the troublesome loop: logging.debug("Created guest, looking to see if it is running") # sleep in .25 second increments until either a) we find # our domain or b) it's been 5 seconds. this is so that # we can try to gracefully handle domain creation failures num = 0 d = None while num < (5 / .25): # 5 seconds, .25 second sleeps try: d = self.conn.lookupByName(self.name) break except libvirt.libvirtError, e: logging.debug("No guest running yet " + str(e)) pass num += 1 time.sleep(0.25) -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903

2 2

[Libvir] PATCH 0/20: Re-factor libvirtd / QEMU driver
by Daniel P. Berrange 28 Jun '07

28 Jun '07

The work to refactor the QEMU driver to use the regular libvirt driver API is now complete. The next 20 (!) patches provide fairly fine-grained steps refactoring the code. Aside from that which adds an event loop, and the very last one, they should all be pretty much straightforward refactoring with no functional change. With this patch series fully applied there is now only a single daemon which can serve both remote & QEMU drivers in one go, with no deadlock issues. 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 54

[Libvir] libvirt 0.1.8 Help
by Omer Khalid 27 Jun '07

27 Jun '07

Hi, I have the following code working on libvirt 0.1.9: ######################################## conn = libvirt.openReadOnly(None) if conn == None: print 'Failed to open connection to the hypervisor' #sys.exit(1) try: domains = conn.listDomainsID() num = conn.numOfDomains() except: print 'Failed to find the list of domains' for i in range(num): try: dom0 = conn.lookupByID(domains[i]) domInfo = dom0.info() except: print "Unexpected error:", sys.exc_info() ############################################## For legacy reason, I have to get it working on libvirt 0.1.8 but I am constantly getting the following error: Unexpected error: (<class libvirt.libvirtError at 0xb7f49f2c>, < libvirt.libvirtError instance at 0xb7f4f2cc>, <traceback object at 0xb7f44c5c>) Any help would be much appreciated! Cheers Omer -- ---------------------------------------------------------- CERN – European Organization for Nuclear Research, IT Department, CH-1211 Geneva 23, Switzerland Phone: +41 (0) 22 767 2224 Fax: +41 (0) 22 766 8683 E-mail : Omer.Khalid(a)cern.ch Homepage: http://cern.ch/Omer.Khalid

3 4

[Libvir] [PATCH] Move common buffer code to lib/ directory
by Richard W.M. Jones 26 Jun '07

26 Jun '07

I haven't quite got to my goal of removing _GNU_SOURCE (yet), but this patch along the way creates a lib/ subdirectory and moves the common buffer code (from qemud/buf.[ch] and in src/xml.[ch]) there. There are many, many places which call the buffer functions without checking the return value. I have manually verified / fixed up the calls which do bother to check return values, but not added any more checks where they don't. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903

3 2