- Devel - libvirt List Archives

[Libvir] [PATCH] Add help to qemu daemon, and a small bug
by Richard W.M. Jones 03 Apr '07

03 Apr '07

This patch adds command-line help to the libvirt qemu daemon. One small bug: On my machine at least, QEMUD_PID_FILE is defined as (literally) "${prefix}/var/run/libvirt_qemud.pid". It shouldn't have the "${prefix}" at the beginning, and even if that is fixed it looks like this could result in a path like "/usr/var/run/..." which would be wrong. I fiddled with AC_DEFINE_UNQUOTED and the quoting of the string itself inside configure.in and I couldn't work out how to get the quoting right. Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 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. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA) and David Owens (Ireland)

1 0

[Libvir] Added python binding for autostart flag
by Daniel P. Berrange 03 Apr '07

03 Apr '07

The vir{Domain,Network}GetAutostart() methods are missing from the python binding because they used an int * as a parameter. The attached patch adds a hand-written impl of these two APIs for the python binding. 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 1

[Libvir] Unified Xen patch (incomplete, for discussion)
by Richard W.M. Jones 02 Apr '07

02 Apr '07

I've spent the last day or so producing a unified Xen patch. In such a model a connection contains only a single underlying driver, and it is the responsibility of the (unified) Xen driver to try all the different methods it knows. Attached is an incomplete patch for this, for discussion, plus the two extra files of the unified driver itself (for some reason CVS won't give me a diff including these added files). Some points to note: The new structure of the drivers is: <pre> libvirt.c | +------- xen_unified.c | | | +--- xen_internal.c (hypervisor) | | | +--- proxy_internal.c * (proxy) | | | +--- xend_internal.c * (XenD) | | | +--- xs_internal.c (XenStore) | | | +--- xm_internal.c * (inactive domains) | +-------- qemu_internal.c * | +-------- test.c * = not updated yet, so these don't compile </pre> I haven't renamed the Xen sub-drivers. That's really to make the patch easier to read. There is definitely a case for renaming the drivers more logically to reflect the structure above. All Xen-specific hacks in libvirt.c have been moved to xen_unified.c Error handling in the case where a driver doesn't support a libvirt function is now considerably better. Each driver keeps its private data private. At the moment xen_unified pretty much does the "try the drivers in a loop until one succeeds" strategy which used to be in libvirt.c. There is a case for making it do direct calls to the "right" driver, but for simplicity I haven't gone that far. Again for simplicity the Xen sub-drivers still use struct virDriver. They should use their own custom 'struct virXenDriver' or whatever. The effects of this are slight but noticable - some parameters are now no longer used in the sub-drivers, so marked ATTRIBUTE_UNUSED. There is also a single networkDriver pointer in the connect struct. We should modify the functions to handle the case where this is NULL because we couldn't bring up the network functions (all network functions in this case would just return an error). libvirt in CVS fails to run if libvirtd isn't up. I won't be able to get back to this before tomorrow afternoon, so plenty of time for discussion! Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA) and David Owens (Ireland)

3 8

[Libvir] [PATCH] fix_setmem_setmaxmem_help message
by Atsushi SAKAI 02 Apr '07

02 Apr '07

Hi, This patch intends to fix the help message of setmem/setmaxmem.(from bytes to kilobytes) Signed-off-by: Atsushi SAKAI <sakaia(a)jp.fujitsu.com> Thanks Atsushi SAKAI

2 1

Re: [Libvir] [patch 0/5] Misc. fixes to iptables support
by Mark McLoughlin 30 Mar '07

30 Mar '07

On Wed, 2007-03-21 at 12:47 +0000, Mark McLoughlin wrote: > Hey, > What follows is a few misc patches for qemud's iptables > support. The main point is to add reload-on-HUP as suggested by > danpb. > > Comments welcome .. Hmm, I nearly forgot about these patches ... no objections, then? Cheers, Mark.

3 2

[Libvir] Migration support
by Simon Boulet 30 Mar '07

30 Mar '07

Hi, What is the status of migration support for Libvirt, either offline or live migration? My understanding of Libvirt is that it does not support connecting to remote nodes yet. Thank you Simon

3 2

[Libvir] [PATCH] XPath accessors cleanup
by Daniel Veillard 30 Mar '07

30 Mar '07

It a long time cleanup TODO, the XML parsing code of xml.c is invaded with libxml2 specific XPath lookup code, this patch defines 5 clearly isolated accessor functions and then fixes all the src/xml.c code to use those. IMHO this clearly improve readability and maintanability and I think I also found a couple of bugs in the process. The patch enclosed only fixes xml.c and xml.h, the next step is to chase other modules to apply the same treatment if needed. 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] [PATCH] Enable USB device setting information handling on virsh.
by Masayuki Sunou 29 Mar '07

29 Mar '07

Hi When domHVM started by virsh create, the information of USB setting is not saved by vish dumpxml. The reason is that USB setting is defined by Xen itself, not virsh. This patch enables USB device setting information handling on virsh create/virsh dumpxml. Signed-off-by: Masayuki Sunou <fj1826dm(a)aa.jp.fujitsu.com> Thanks, Masayuki Sunou Index: libvirt/src/xend_internal.c =================================================================== RCS file: /data/cvs/libvirt/src/xend_internal.c,v retrieving revision 1.99 diff -u -p -r1.99 xend_internal.c --- libvirt/src/xend_internal.c 6 Mar 2007 21:55:44 -0000 1.99 +++ libvirt/src/xend_internal.c 7 Mar 2007 08:28:55 -0000 @@ -1666,6 +1666,13 @@ xend_parse_sexp_desc(virConnectPtr conn, free(tty); } + tmp = sexpr_node(root, "domain/image/hvm/usbdevice"); + if ((tmp != NULL) && (tmp[0] != 0)) { + virBufferVSprintf(&buf, " <usb usbdevice='%s'/>\n", tmp); + } else if (sexpr_int(root, "domain/image/hvm/usb")) { + virBufferAdd(&buf, " <usb/>\n", 11 ); + } + virBufferAdd(&buf, " </devices>\n", 13); virBufferAdd(&buf, "</domain>\n", 10); Index: libvirt/src/xml.c =================================================================== RCS file: /data/cvs/libvirt/src/xml.c,v retrieving revision 1.62 diff -u -p -r1.62 xml.c --- libvirt/src/xml.c 6 Mar 2007 20:00:17 -0000 1.62 +++ libvirt/src/xml.c 7 Mar 2007 08:28:55 -0000 @@ -524,6 +524,20 @@ virDomainParseXMLOSDescHVM(virConnectPtr } xmlXPathFreeObject(obj); + obj = xmlXPathEval(BAD_CAST "/domain/devices/usb", ctxt); + if ((obj != NULL) && (obj->type == XPATH_NODESET) && + (obj->nodesetval != NULL) && (obj->nodesetval->nodeNr == 1)) { + virBufferAdd(buf, "(usb 1)", 7); + xmlXPathFreeObject(obj); + obj = xmlXPathEval(BAD_CAST "string(/domain/devices/usb/@usbdevice)", ctxt); + if ((obj != NULL) && (obj->type == XPATH_STRING) && + (obj->stringval != NULL) && (obj->stringval[0] != 0)) { + virBufferVSprintf(buf, "(usbdevice '%s')", obj->stringval); + } + } + if (obj) + xmlXPathFreeObject(obj); + virBufferAdd(buf, "))", 2); if (boot_dev)

4 10

[Libvir] [PATCH] Python bindings now generate exceptions for libvirt errors
by Richard W.M. Jones 28 Mar '07

28 Mar '07

Following on from this thread: https://www.redhat.com/archives/libvir-list/2007-March/thread.html#00341 The first attachment is a patch which changes the generated Python bindings so that they always raise an exception when an underlying error occurs in the C libvirt library. The second attachment is for information only (not to be applied) - it shows the differences in the generated file libvirtclass.py. I have checked each of these changes by hand against both the libvirt.c interface description and the C implementation of the Python bindings (libvir.c and libvirt-py.c), and each change seems correct. I have _not_ tested this against virt-manager. It is quite possible that virt-manager will cease to work if it wasn't checking the return values from affected functions carefully. I'll check this later today and supply a patch (to virt-manager) if necessary. I have some additional questions about the Python bindings, but I'll put those in a separate thread. Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 "[Negative numbers] darken the very whole doctrines of the equations and make dark of the things which are in their nature excessively obvious and simple" (Francis Maseres FRS, mathematician, 1759)

4 15

[Libvir] A couple of questions about the Python bindings
by Richard W.M. Jones 28 Mar '07

28 Mar '07

virDomainGetUUIDString, virDomainPinVcpu, virNetworkGetUUIDString: These functions don't seem to check whether the parameters are correct. For example, virDomainGetUUIDString doesn't check if the buffer parameter passed from Python is large enough to take the UUID string. virDomainPinVcpu is just plain strange (but I guess that strangeness eminates from the Xen implementation), but it seems possible for the Python code to be wrong about the length of the Vcpu map (string). Shouldn't the length be taken from the string itself? virDomainUndefine, virNetworkUndefine: It's unclear from the libvirt documentation, but it sounds as if these functions invalidate (free) the virDomainPtr / virNetworkPtr object passed to them. (In fact, the Xen implementation of virDomainPtr at least _doesn't_ free it - is that a bug?) If this is the case, then the Python bindings ought to set self._o = None. Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 "[Negative numbers] darken the very whole doctrines of the equations and make dark of the things which are in their nature excessively obvious and simple" (Francis Maseres FRS, mathematician, 1759)

3 2