April 2007 - Devel - libvirt List Archives

[Libvir] Documentation for remote patch (for discussion only)
by Richard W.M. Jones 18 Apr '07

18 Apr '07

Attached, a patch which gives almost complete documentation for the remote patch. Highlights: * Remote URIs * Transports * Limitations * Implementation 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)

2 4

[Libvir] [PATCH] Tidy up the error messages produced by test driver
by Richard W.M. Jones 18 Apr '07

18 Apr '07

This minor patch: * Introduces a VIR_FROM_TEST class of errors and makes errors generated by test come from that class. * Provides a reasonable error message if the user forgets to supply a path. Also stops the driver from trying to open ("/"). Example: $ src/virsh -c test:/// capabilities libvir: Test error : invalid argument in testOpen: supply a path or use test:///default lt-virsh: error: failed to connect to the hypervisor * Arranges that Xen-unified appears last in the list of drivers, because qemu and test have well-defined URI syntaxes so can be checked first. 'make check' passes all tests with this patch. 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)

2 2

[Libvir] Remote patch 2007-04-17 (for discussion only)
by Richard W.M. Jones 17 Apr '07

17 Apr '07

Attached is the latest remote patch which should apply against either CVS or the just-released libvirt-0.2.2. It's only for discussion because it's not quite complete yet. This patch includes Dan's QEMUD/XDR patch. And it basically follows the plan outlined in [1]. Problems: * QEMUD deadlocks when you try to call qemu over remote (eg. try: virsh -c qemu+unix:///system?socket=/path/to/libvirt/qemud-sock capabilities). This is because qemud tries to connect back to itself, but it is in the middle of handling the request, so it doesn't respond. * Opening Xen over remote fails, because the Xen unified driver doesn't understand URLs like xen:///. I'm not sure if it ever did, or if this is a regresssion, but it certainly _ought_ to support this style of URLs. * The server will quite happily answer a mixture of remote and qemud requests even on the same connection (of course, libvirt would never generate such a mix). I'm not sure if this is a problem. To do: * Only supports a small subset of calls (not difficult to do but I'm trying to get the framework working first). * Needs GnuTLS support on the server side (copy & paste of the code from the old remote patch). * Needs to support TCP sockets on the server side. Rich. [1] https://www.redhat.com/archives/libvir-list/2007-March/msg00333.html -- 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] Release of libvirt-0.2.2
by Daniel Veillard 17 Apr '07

17 Apr '07

Time for the monthly release ! A lot of bug fixes have accumulated, and support for the upcoming Xen-3.0.5 should hopefully be ready: ftp://libvirt.org/libvirt/ Documentation: - fix errors due to Amaya (with Simon Hernandez) - virsh uses kB not bytes (Atsushi SAKAI) - add command line help to qemud (Richard Jones) - xenUnifiedRegister docs (Atsushi SAKAI) - strings typos (Nikolay Sivov) - ilocalization probalem raised by Thomas Canniot Bug fixes: - virsh memory values test (Masayuki Sunou) - operations without libvirt_qemud (Atsushi SAKAI) - fix spec file (Florian La Roche - Jeremy Katz - Michael Schwendt) - direct hypervisor call (Atsushi SAKAI) - buffer overflow on qemu networking command (Daniel Berrange) - buffer overflow in quemud (Daniel Berrange) - virsh vcpupin bug (Masayuki Sunou) - host PAE detections and strcuctures size (Richard Jones) - Xen PAE flag handling (Daniel Berrange) - bridged config configuration (Daniel Berrange) - erroneous XEN_V2_OP_SETMAXMEM value (Masayuki Sunou) - memory free error (Mark McLoughlin) - set VIR_CONNECT_RO on read-only connections (S.Sakamoto) - avoid memory explosion bug (Daniel Berrange) - integer overflow for qemu CPU time (Daniel Berrange) - QEMU binary path check (Daniel Berrange) Cleanups: - remove some global variables (Jim Meyering) - printf-style functions checks (Jim Meyering) - better virsh error messages - increase compiler checkings and security (Daniel Berrange) - virBufferGrow usage and docs - use calloc instead of malloc/memset - replace all sprintf by snprintf - avoid configure clobbering user's CTAGS (Jim Meyering) - signal handler error cleanup (Richard Jones) - iptables internal code claenup (Mark McLoughlin) - unified Xen driver (Richard Jones) - cleanup XPath libxml2 calls - IPTables rules tightening (Daniel Berrange) Improvements: - more regression tests on XML (Daniel Berrange) - Python bindings now generate exception in error cases (Richard Jones) - Python bindings for vir*GetAutoStart (Daniel Berrange) - handling of CD-Rom device without device name (Nobuhiro Itou) - fix hypervisor call to work with Xen 3.0.5 (Daniel Berrange) - DomainGetOSType for inactive domains (Daniel Berrange) - multiple boot devices for HVM (Daniel Berrange) thanks to everybody who helped, by raising problems or contributing ideas and patches ! 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] [PATCH] About remote operation restrictions of a general user
by S.Sakamoto 17 Apr '07

17 Apr '07

Hi When I use virt-connect in a general user, and a general user can perform operation system such as "start". So, here's the patch adds to can't use operation system in "connect" in a general user. Signed-off-by: Shigeki Sakamoto <fj0588di(a)aa.jp.fujitsu.com> Thanks, Shigeki Sakamoto. Index: src/virsh.c =================================================================== RCS file: /data/cvs/libvirt/src/virsh.c,v retrieving revision 1.71 diff -u -p -r1.71 virsh.c --- src/virsh.c 2 Apr 2007 11:56:38 -0000 1.71 +++ src/virsh.c 4 Apr 2007 05:51:08 -0000 @@ -360,6 +360,8 @@ static int cmdConnect(vshControl * ctl, vshCmd * cmd) { int ro = vshCommandOptBool(cmd, "readonly"); + virDomainPtr dom; + char *ret; if (ctl->conn) { if (virConnectClose(ctl->conn) != 0) { @@ -374,12 +376,25 @@ cmdConnect(vshControl * ctl, vshCmd * cm free(ctl->name); ctl->name = vshStrdup(ctl, vshCommandOptString(cmd, "name", NULL)); + ctl->conn = virConnectOpenReadOnly(ctl->name); + ctl->readonly = 1; + if (!ro && ctl->uid != 0){ + dom = virDomainLookupByID(ctl->conn, 0); + if (dom==NULL) + return FALSE; + ret = virDomainGetXMLDesc(dom, 0); + if (NULL != strstr(ret, "domain type='xen'")) + ro = 1; + free(ret); + } if (!ro) { + if (virConnectClose(ctl->conn) != 0) { + vshError(ctl, FALSE, + _("Failed to disconnect from the hypervisor")); + return FALSE; + } ctl->conn = virConnectOpen(ctl->name); ctl->readonly = 0; - } else { - ctl->conn = virConnectOpenReadOnly(ctl->name); - ctl->readonly = 1; } if (!ctl->conn) @@ -3175,6 +3190,9 @@ _vshStrdup(vshControl * ctl, const char static int vshInit(vshControl * ctl) { + virDomainPtr dom; + char *ret; + if (ctl->conn) return FALSE; @@ -3188,8 +3206,26 @@ vshInit(vshControl * ctl) !strcasecmp(ctl->name, "xen")) && ctl->uid != 0) ctl->readonly = 1; - if (!ctl->readonly) + if (!ctl->readonly) { ctl->conn = virConnectOpen(ctl->name); + + if (ctl->uid != 0){ + dom = virDomainLookupByID(ctl->conn, 0); + if (dom==NULL) + return FALSE; + ret = virDomainGetXMLDesc(dom, 0); + if (NULL != strstr(ret, "domain type='xen'")) { + if (virConnectClose(ctl->conn) != 0) { + vshError(ctl, FALSE, + _("Failed to disconnect from the hypervisor")); + return FALSE; + } + ctl->conn = virConnectOpenReadOnly(ctl->name); + ctl->readonly = 1; + } + free(ret); + } + } else ctl->conn = virConnectOpenReadOnly(ctl->name);

4 9

[Libvir] [PATCH] virsh version
by Atsushi SAKAI 16 Apr '07

16 Apr '07

Hi, Currently virsh version is not work. Currently just show the libvirt version only. This is caused by mis-matching of xen(xen_unified.c) and Xen(libvirt.c) . I do not know the policy. So I attached 2 Pattern. Thanks Atsushi SAKAI =================Pattern1================ --- libvirt.orig/src/xen_unified.c 2007-04-13 09:43:57.000000000 +0900 +++ libvirt.Xen/src/xen_unified.c 2007-04-13 20:02:46.000000000 +0900 @@ -89,8 +89,8 @@ xenUnifiedOpen (virConnectPtr conn, cons /* If name == NULL, name == "", or begins with "xen", then it's for us. */ if (!name || name[0] == '\0') - name = "xen"; - if (strncasecmp (name, "xen", 3) != 0) + name = "Xen"; + if (strncasecmp (name, "Xen", 3) != 0) return VIR_DRV_OPEN_DECLINED; /* Allocate per-connection private data. */ @@ -719,7 +719,7 @@ xenUnifiedDomainSetAutostart (virDomainP /* The interface which we export upwards to libvirt.c. */ static virDriver xenUnifiedDriver = { .no = VIR_DRV_XEN_UNIFIED, - .name = "xen", + .name = "Xen", .ver = VERSION, .open = xenUnifiedOpen, .close = xenUnifiedClose, =================Pattern2================ --- libvirt.orig/src/libvirt.c 2007-04-12 23:18:39.000000000 +0900 +++ libvirt.Xen/src/libvirt.c 2007-04-13 20:09:02.000000000 +0900 @@ -246,7 +246,7 @@ virGetVersion(unsigned long *libVer, con if (typeVer != NULL) { if (type == NULL) - type = "Xen"; + type = "xen"; for (i = 0;i < virDriverTabCount;i++) { if ((virDriverTab[i] != NULL) && (!strcmp(virDriverTab[i]->name, type))) {

2 1

[Libvir] PATCH: Check for /usr/bin/qemu* binaries before starting guest
by Daniel P. Berrange 16 Apr '07

16 Apr '07

The attached patch fixes two issues - It explicitly checks to see if the requested /usr/bin/qemu* binary actually exists before fork()/exec()'ing it. While its technically possible to catch the execve() failure of ENOENT, its a real pain to feed this error back to the qemu daemon because we're in a sub-process at that point. The obvious & easy solution is to thus check to see if the binary exists before trying to fork. - It only passes the -no-kqemu flag if we're running matching arch to the host. Previously it would pass the -no-kqemu flag even if running an x86_64 guest on i686 platform - QEMU then exited with error because the -no-kqemu flag is not recognised on x86_64 when running on i686 host. 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 -=|

4 3

[Libvir] PATCH: Added QEMU driver for virDomainGetOSType method
by Daniel P. Berrange 15 Apr '07

15 Apr '07

For some reason we never had an impl of the virDomainGetOSType method for the QEMU driver - and for even more bizarre reason it wasn't failing, because the old libvirt.c code hardcoded 'linux' if there was no impl. The latter was fixed by Rich, with the xenUnified driver, so exposing the former bug. This patch adds a simple impl for QEMU - there's no need to talk to the daemon in this case because QEMU guests can only ever by of type 'hvm'. 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] PATCH: Fix exception reporting for virNetwork / virDomain python methods
by Daniel P. Berrange 15 Apr '07

15 Apr '07

The virError() class in the python bindings will either pick up the global error details, or will extract them from the virConnect private error details. For the latter to work, you must pass in a virConnect object when creating the virError. I'd previously fixed up the generator so that was done correctly for any method on virConnectPtr, however, I forgot that a similar fix was needed for the virDomainPtr / virNetworkPtr related methods. Currently we're getting back zero useful information in the python layer with a virDomain* or virNetwork* method fails. Unfortunately, given a virDomainPtr / virNetworkPtr object in python, there is no easy way to get back the virConnectPtr object. So this patch does two things - it passes the virConnect python object into the constructor of the virDomain / virNetwork python objects, and then stores it in a private _conn attribute. Then, the virNetwork/virDomain objects are passed into the virError() classes when needeed so it can get hold of the private error details. So with this patch, virt-manager will get sensible error information when attempting to start an inactive guest, or when doing device hot-add/remove. BTW, since we now store an explicit reference to the virConnect object, I removed the generic 'self.ref' back-reference. 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 1

[Libvir] PATCH: support Xen 3.0.5
by Daniel P. Berrange 13 Apr '07

13 Apr '07

I've been doing some testing with current xen-unstable (ie what will very shortly be 3.0.5) and came across a whole bunch of things which needed fixing - some expected, others not expected. The attached patch addresses the following issues: - Many of the hypercalls have their structs changed so that int64_t or 'foo *' members are always 64-bit aligned even on 32-bit platforms. This is part of the work to allow 32-bit Dom0/DomU to work on 64-bit hypervisor. For the int64_t types I had to annotate with __attribute__((aligned(8))). This did not work for pointer data types, so I for those I had to do a more complex hack with union { foo *v; int64_t pad __attribute__((aligned(8))) } This matches what is done in the public (BSD licensed) Xen HV header files. We already had ways to deal with v0 vs v2 hypercalls structs. This change is still techincally v2, but just a minor revision of the domctl or sysctl interfaces. Thus I have named the extra structs v2d5 or v2s3 to indicated hypercall version 2, domctl version 5 or hypercall version 2, sysctl version 3 respectively. - The 'flags' field in the getdomaininfo hypercall now has an extra flag defined '(1<<1)' which was previously not used, is now used to indicate that the guest is HVM. Thus when fetching domain state, we have to mask out that flag, otherwise we'll never match the correct paused/running/ blocked/etc states. - In the xenHypervisorNumOfDomains method, under certain scenarios we will re-try the hypercall, allocating a bigger memory buffer. Well due to the ABI alignment changes we hit that scenario everytime, and ended up allocating a multi-GB buffer :-) The fixed structs sort this out, but as a preventative measure for any future HV changes the patch will break out of the loop at the 10,000 guest mark to avoid allocating GB of memory. - The unified Xen driver broke the GetVCPUs method - it was mistakenly checking for return value == 0, instead of > 0. Trivial fix. - The method to open the XenD connection was calling xenDaemonGetVersion to test if the connection succeeded. But then also calling the xend_detect_config_version which does pretty much same thing. So I removed the former, and now we only do the latter as a 'ping' test when opening. This removes 1 HTTP GET which is worthwhile performance boost given how horrifically slow XenD is. - The HVM SEXPR for configuring the VNC / SDL graphics is no longere part of the (image) block. it now matches the PVFB graphics config and is an explicit (vfb) block within the (devices) block. So if xend_config_format >= 4 we use the new style config - this is assuming upstream XenD is patched to increment xend_config_format from 3 to 4 - I send a patch & am confident it will be applied very shortly. - The QEMU device model allows a user to specify multiple devices for the boot order, eg 'andc' to indicated 'floppy', 'network' 'cdrom', 'disk'. We assumed it was a single letter only. I now serialize this into multiple <boot dev='XXX'/> elements, ordered according to priority. The XML -> SEXPR conversion allows the same. I've tested all this on a 32-bit Dom0 running on 32-bit HV, and 64-bit HV, but not tested a 64-bit Dom0 on 64-bit HV. I'm pretty sure it'll work,but if anyone is runnning 64-on-64 please test this patch. 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 -=|

4 13

[Libvir] [PATCH][RFC] shows scheduler information
by Atsushi SAKAI 12 Apr '07

12 Apr '07

Hi, This patch intends add a showing function of scheduler information. If apply this patch to current revision 1.490 and type virsh dominfo 0 then shows following scheduler information. Currently I assume credit scheduler only. getting function is implemented but setting function is not yet. I just waiting for comments. Id: 0 Name: Domain-0 UUID: 00000000-0000-0000-0000-000000000000 OS Type: linux State: running CPU(s): 1 CPU time: 432.7s Max memory: no limit Used memory: 1933312 kB scheduler info 5 256 0 SchedulerID: 5 Weight: 256 Cap: 0 Thanks Atsushi SAKAI

4 26

[Libvir] [PATCH] Check ReadOnly-flag
by S.Sakamoto 12 Apr '07

12 Apr '07

Hi When a general user uses command "# virsh --connect xen start domain", don't become an error, and domain start. Because ReadOnly-flag is not "1" when a general user uses it. So, here's the patch adds to check ReadOnly-flag. Signed-off-by: Shigeki Sakamoto <fj0588di(a)aa.jp.fujitsu.com> Thanks, Shigeki Sakamoto. Index: src/libvirt.c =================================================================== RCS file: /data/cvs/libvirt/src/libvirt.c,v retrieving revision 1.66 diff -u -p -r1.66 libvirt.c --- src/libvirt.c 4 Apr 2007 14:19:49 -0000 1.66 +++ src/libvirt.c 12 Apr 2007 07:55:32 -0000 @@ -301,6 +301,10 @@ do_open (const char *name, int flags) break; } } + + if (flags & VIR_DRV_OPEN_RO) { + ret->flags = VIR_CONNECT_RO; + } return ret;

2 1

[Libvir] [Q] about virsh-connect
by S.Sakamoto 12 Apr '07

12 Apr '07

Hi, I have a question. 　Previously(libvirt 0.2.1) We can do remote connection via URI successfully.. (virsh --connect http://127.0.0.1:8000 list) But Current version(libvirt-current) cannot connect remotely. This event occurs in both general user and administrator. I investigate the code and found folloing code is included (see line 94) If "name" is not "xen", decline connection. ("# virsh --help connect" is output with "<name> hypervisor connection URI") Is this change intentionally? xen_unified.c =========================================================== 84| static int 85| xenUnifiedOpen (virConnectPtr conn, const char *name, int flags) 86| { 87| int i, j; 88| xenUnifiedPrivatePtr priv; 89| 90| /* If name == NULL, name == "", or begins with "xen", then it's for us. / 91| if (!name || name[0] == '\0') 92| name = "xen"; 93| if (strncasecmp (name, "xen", 3) != 0) 94| return VIR_DRV_OPEN_DECLINED; =========================================================== Thanks, Shigeki Sakamoto.

2 1

[Libvir] [PATCH] virsh dumpxml and create fails with no UNAME cdrom device
by Nobuhiro Itou 11 Apr '07

11 Apr '07

Hi, In the xmexample.hvm(/etc/xen/xmexample.hvm), no UNAME cdrom device is written. disk = [ 'file:/var/images/min-el3-i386.img,hda,w', ',hdc:cdrom,r' ] But virsh dumpxml fails if the domain has virtual cdrom device without UNAME. And virsh create fails if the domain config XML has no UNAME cdrom device, too. The attached patch adds to solve this problem. Signed-off-by: Nobuhiro Itou <fj0873gn(a)aa.jp.fujitsu.com> Thanks, Nobuhiro Itou.

2 3

[Libvir] RFC [0/3]: Re-factor QEMU daemon protocol to use XDR
by Daniel P. Berrange 11 Apr '07

11 Apr '07

I've been thinking about a way to move forward on the remote management capabilities in libvirt since our last list discussion didn't come to any clear agreement. The current situation - QEMUD daemon uses a hand-crafted protocol basically just dumping structs on the wire. Key points: - Fairly simple to understand code for marshalling/demarshalling - Very low overhead on wire - Not safe endianess - Not safe wrt to architecture data alignment rules - No authentication/encryption - Server driver specific to QEMU - The generic libvirt daemon uses SunRPC as the underlying protocol. - Protocol versioning - Safe wrt to endianess - Safe wrt to architecture data alignment rules - Added TLS encryption / SSH tunneling - Generic for any libvirt backend - Doesn't work with non-blocking sockets due to SunRPC limitations - SunRPC api is not well known / 'wierd' - Call + reply only; no async signals from server Looking at the current impl of the generic libvirt daemon there are some things which strike me: 1. We have an extra layer of marshalling/demarshalling calls. ie the methods in the libvirt driver, call to the SunRPC marshalling methods, which populate an XDR generated struct, which call the XDR routines to write the data. 2. The main loop doesn't allow us to listen for other non-SunRPC file handles (eg the QEMU/dnsmasq processes). 3. We've basically re-written the the SunRPC svc*_create methods to get support for TLS / SSH We are going to need to address 2 by creating our own mainloop impl. For point 1 we can have the libvirt driver populate the XDR struct directly and eliminate the SunRPC generated marshalling stubs completely. If we did that, and given points 2 & 3, we're basically left using very little of the SunRPC capabilities at all. Pretty much only thing it is doing for us at that point is the protocol versioning, and giving us a horrific API which doesn't support non-blocking IO so forces us to be multi-threads or multi-process. So, I'm thinking why don't we just use XDR directly & be done with it. As an experiment I took the existing QEMU daemon & driver and re-factored the hand written binary protocol to use XDR instead. Looking at the diffstat - there was basically no appreciable difference in codesize after the re-factoring, and we get the added benefit of being endianness & alignment safe. qemud/Makefile.am | 15 + qemud/conf.c | 1 qemud/dispatch.c | 538 ++++++++++++++++------------------------------ qemud/dispatch.h | 2 qemud/internal.h | 21 + qemud/protocol.h | 329 ---------------------------- qemud/protocol.x | 608 ++++++++++++++++++++++++++++++++++++++++++++++++++++ qemud/qemud.c | 189 +++++++++++----- qemud/uuid.c | 1 src/Makefile.am | 11 src/internal.h | 2 src/qemu_internal.c | 593 ++++++++++++++++++++++++++------------------------ 12 files changed, 1288 insertions(+), 1022 deletions(-) The particular changes I'll explain in the next 3 mails where I attach the patches. Meanwhile though, I'm thinking we could take approach of incremental code refactoring, pulling in all the various capabilities from the remote patch (except for the SunRPC demarshalling itself) to the QEMU daemon. At each stage having a working daemon & client but with ever growing capabilities, until it provides full remote management. 1. Add an extra initial message type to do a major/minor version number exchange. Based on the negotiated versions, the server can activate or deactivate particular requests it allows from the client. 2. Add in the URI parsing routines to the qemud_interal.c driver, but only allow use of QEMU initially. 3. Add in the TLS + SSH client & server socket setup code to give an authenticated & secured remote channel 4. Re-factor qemud/dispatch.c so that it calls into the regular libvirt API for the Xen case, but keeps calling qemud/driver.c for the QEMU case. BTW, these patches are not intended to be applied to CVS - they're for discussion purposes at this stage. That said, they are fully functional so you can apply them to your checkout & you should be able run all the existing virsh commands against the libvirt_qemud. Just make sure you patch & rebuild both the client & server ;-) 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 12

[Libvir] [Q] about Missing type converters in python/generator.py
by Atsushi SAKAI 11 Apr '07

11 Apr '07

Hi, I try to make a python bindings. But I run the python/generator.py. The following messages are appeared. (Missing type converters:) Is there any advice to solve this? ================== /usr/lib/python2.4/xmllib.py:9: DeprecationWarning: The xmllib module is obsolete. Use xml.sax instead. warnings.warn("The xmllib module is obsolete. Use xml.sax instead.", DeprecationWarning) Found 79 functions in libvirt-api.xml Found 1 functions in libvirt-python-api.xml Generated 67 wrapper functions, 9 failed, 4 skipped Missing type converters: virErrorPtr:4 virVcpuInfoPtr:1 void *:2 unsigned long *:2 ================== Thanks Atsushi SAKAI

2 2

[Libvir] [PATCH] Add xenUnifiedRegister Comment for xml files
by Atsushi SAKAI 10 Apr '07

10 Apr '07

Hi, I run apibuild.py on docs, following messages are appeared. Missing comment for function xenUnifiedDriver This patch fixes this. If comments are not appropriate, please change it. Thanks Atsushi SAKAI --- libvirt.0410/src/xen_unified.c 2007-04-04 23:19:49.000000000 +0900 +++ libvirt.xenuni/src/xen_unified.c 2007-04-10 13:30:56.000000000 +0900 @@ -762,6 +762,13 @@ static virDriver xenUnifiedDriver = { .domainSetAutostart = xenUnifiedDomainSetAutostart, }; +/** + * xenUnifiedRegister: + * + * Register xen related drivers + * + * Returns the driver priority or -1 in case of error. + */ int xenUnifiedRegister (void) {

2 2

[Libvir] Virtual network iptables rules
by Daniel P. Berrange 05 Apr '07

05 Apr '07

Warning, this is a long & complicated email with lots of horrible details :-) I've long been a little confused with the way iptables & bridging interacts, so set out to do some experiments. I added a -j LOG rule to every single chain in both the filter & nat tables, and then tried various traffic patterns, to see which chains were traversed & in which order. There are 2 types of config I considered - virtual networking, and shared physical device. For both these I tried with net.bridge.bridge-nf-call-iptables on & off. This gave 4 scenarios to test with. For the test I simply did 'ping -c 1 <ip addr>', which gives a simple roundtrip with a single packet in each direction. The results were as follows.... Scenario 1: Virtual network =========================== net.bridge.bridge-nf-call-iptables = 0 Host: eth0 -> Internet virbr0 -> MASQUERADE to eth0 Guest: vif1.0 -> virbr0 Traffic: Guest -> Google ------------------------ Out: NAT-PREROUTING IN=virbr0 OUT= SRC=192.168.122.47 DST=64.233.167.99 FORWARD IN=virbr0 OUT=eth0 SRC=192.168.122.47 DST=64.233.167.99 NAT-POSTROUTING IN= OUT=eth0 SRC=192.168.122.47 DST=64.233.167.99 Back: FORWARD IN=eth0 OUT=virbr0 SRC=64.233.167.99 DST=192.168.122.47 Traffic: Guest -> Host ---------------------- Out: NAT-PREROUTING IN=virbr0 OUT= SRC=192.168.122.47 DST=192.168.122.1 INPUT IN=virbr0 OUT= SRC=192.168.122.47 DST=192.168.122.1 Back: OUTPUT IN= OUT=virbr0 SRC=192.168.122.1 DST=192.168.122.47 Traffic: Host -> Guest ---------------------- Out: NAT-OUTPUT IN= OUT=virbr0 SRC=192.168.122.1 DST=192.168.122.47 OUTPUT IN= OUT=virbr0 SRC=192.168.122.1 DST=192.168.122.47 NAT-POSTROUTING IN= OUT=virbr0 SRC=192.168.122.1 DST=192.168.122.47 Back: INPUT IN=virbr0 OUT= SRC=192.168.122.47 DST=192.168.122.1 Scenario 2: Virtual network =========================== net.bridge.bridge-nf-call-iptables = 1 Host: eth0 -> Internet virbr0 -> MASQUERADE to eth0 Guest: vif1.0 -> virbr0 Traffic: Guest -> Google ------------------------ Out: NAT-PREROUTING IN=virbr0 OUT= PHYSIN=vif1.0 SRC=192.168.122.47 DST=64.233.167.99 FORWARD IN=virbr0 OUT=eth0 PHYSIN=vif1.0 SRC=192.168.122.47 DST=64.233.167.99 NAT-POSTROUTING IN= OUT=eth0 PHYSIN=vif1.0 SRC=192.168.122.47 DST=64.233.167.99 Back: FORWARD IN=eth0 OUT=virbr0 SRC=64.233.167.99 DST=192.168.122.47 Traffic: Guest -> Host ---------------------- Out: NAT-PREROUTING IN=virbr0 OUT= PHYSIN=vif1.0 SRC=192.168.122.47 DST=192.168.122.1 INPUT IN=virbr0 OUT= PHYSIN=vif1.0 SRC=192.168.122.47 DST=192.168.122.1 Back: OUTPUT IN= OUT=virbr0 SRC=192.168.122.1 DST=192.168.122.47 Traffic: Host -> Guest ---------------------- Out: NAT-OUTPUT IN= OUT=virbr0 SRC=192.168.122.1 DST=192.168.122.47 OUTPUT IN= OUT=virbr0 SRC=192.168.122.1 DST=192.168.122.47 NAT-POSTROUTING IN= OUT=virbr0 SRC=192.168.122.1 DST=192.168.122.47 Back: INPUT IN=virbr0 OUT= PHYSIN=vif1.0 SRC=192.168.122.47 DST=192.168.122.1 Scenario 3: Shared physical device ================================== net.bridge.bridge-nf-call-iptables = 0 Host: peth1 -> Internet xenbr0 -> peth1 Guest: vif2.0 -> xenbr0 Traffic: Guest -> Google ------------------------ Nada Traffic: Guest -> Host ---------------------- Out: NAT-PREROUTING IN=eth1 OUT= SRC=192.168.254.120 DST=192.168.254.132 INPUT IN=eth1 OUT= SRC=192.168.254.120 DST=192.168.254.132 Back: OUTPUT IN= OUT=eth1 SRC=192.168.254.132 DST=192.168.254.120 Traffic: Host -> Guest ---------------------- Out: NAT-OUTPUT IN= OUT=eth1 SRC=192.168.254.132 DST=192.168.254.120 OUTPUT IN= OUT=eth1 SRC=192.168.254.132 DST=192.168.254.120 NAT-POSTROUTING IN= OUT=eth1 SRC=192.168.254.132 DST=192.168.254.120 Back: INPUT IN=eth1 OUT= SRC=192.168.254.120 DST=192.168.254.132 Scenario 4: Shared physical device ================================== net.bridge.bridge-nf-call-iptables = 1 Host: peth1 -> Internet xenbr0 -> peth1 Guest: vif2.0 -> xenbr0 Traffic: Guest -> Google ------------------------ Out: NAT-PREROUTING IN=xenbr1 OUT= PHYSIN=vif2.0 SRC=192.168.254.120 DST=64.233.167.99 FORWARD IN=xenbr1 OUT=xenbr1 PHYSIN=vif2.0 PHYSOUT=peth1 SRC=192.168.254.120 DST=64.233.167.99 NAT-POSTROUTING IN= OUT=xenbr1 PHYSIN=vif2.0 PHYSOUT=peth1 SRC=192.168.254.120 DST=64.233.167.99 Back: FORWARD IN=xenbr1 OUT=xenbr1 PHYSIN=peth1 PHYSOUT=vif2.0 SRC=64.233.167.99 DST=192.168.254.120 Traffic: Guest -> Host ---------------------- Out: NAT-PREROUTING IN=xenbr1 OUT= PHYSIN=vif2.0 SRC=192.168.254.120 DST=192.168.254.132 FORWARD IN=xenbr1 OUT=xenbr1 PHYSIN=vif2.0 PHYSOUT=vif0.1 SRC=192.168.254.120 DST=192.168.254.132 NAT-POSTROUTING IN= OUT=xenbr1 PHYSIN=vif2.0 PHYSOUT=vif0.1 SRC=192.168.254.120 DST=192.168.254.132 INPUT IN=eth1 OUT= SRC=192.168.254.120 DST=192.168.254.132 Back: OUTPUT IN= OUT=eth1 SRC=192.168.254.132 DST=192.168.254.120 FORWARD IN=xenbr1 OUT=xenbr1 PHYSIN=vif0.1 PHYSOUT=vif2.0 SRC=192.168.254.132 DST=192.168.254.120 Traffic: Host -> Guest ---------------------- Out: NAT-OUTPUT IN= OUT=eth1 SRC=192.168.254.132 DST=192.168.254.120 OUTPUT IN= OUT=eth1 SRC=192.168.254.132 DST=192.168.254.120 NAT-POSTROUTING IN= OUT=eth1 SRC=192.168.254.132 DST=192.168.254.120 FORWARD IN=xenbr1 OUT=xenbr1 PHYSIN=vif0.1 PHYSOUT=vif2.0 SRC=192.168.254.132 DST=192.168.254.120 Back: FORWARD IN=xenbr1 OUT=xenbr1 PHYSIN=vif2.0 PHYSOUT=vif0.1 SRC=192.168.254.120 DST=192.168.254.132 INPUT IN=eth1 OUT= SRC=192.168.254.120 DST=192.168.254.132 Now in this email I'm really only concerned with the first 2 virtual network scernaios. The shared physical device stuff can be ignored henceforth, basically because it 'just works(tm)'. For virtual networks there are basically 3 types of networking config we need to represent in terms of iptables rules, and these need to work for scenrios 1 & 2 - ie regardless of the magic sysctl knob. Here is what we currently implement...... Type 1: Isolated virtual network -------------------------------- - We don't add anything here Type 2: Forwarding to a specific NIC only ----------------------------------------- Chain POSTROUTING (policy ACCEPT 345 packets, 32627 bytes) pkts bytes target prot opt in out source destination 0 0 MASQUERADE all -- * eth1 0.0.0.0/0 0.0.0.0/0 PHYSDEV match ! --physdev-is-bridged Chain FORWARD (policy ACCEPT 29 packets, 2244 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- eth1 vnet0 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 0 0 ACCEPT all -- vnet0 eth1 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- * eth1 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-in vnet0 Chain INPUT (policy ACCEPT 80483 packets, 382M bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT udp -- vnet0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 0 0 ACCEPT tcp -- vnet0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 0 0 ACCEPT udp -- vnet0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:67 0 0 ACCEPT tcp -- vnet0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:67 Type 3: Forwarding to any active NIC ------------------------------------ Chain POSTROUTING (policy ACCEPT 360 packets, 33843 bytes) pkts bytes target prot opt in out source destination 2 476 MASQUERADE all -- * * 0.0.0.0/0 0.0.0.0/0 PHYSDEV match ! --physdev-is-bridged Chain FORWARD (policy ACCEPT 29 packets, 2244 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- * virbr0 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 0 0 ACCEPT all -- virbr0 * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-in virbr0 Chain INPUT (policy ACCEPT 80884 packets, 382M bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT udp -- virbr0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 0 0 ACCEPT tcp -- virbr0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 0 0 ACCEPT udp -- virbr0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:67 0 0 ACCEPT tcp -- virbr0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:67 So how do these shape up, given the traversal scenarios & the overall desire to be as restrictive as possible with traffic. Problem: The INPUT rules are missing altogether for the isolated virtual network so potentially DHCP/DNS will be blocked Solution: Add them - simple bug. Problem: The POSTROUTING rule is too generic so it matches pretty much any kind of traffic, from any virtual network, or even from VPN devices setup by VPNC. Solution: Only masquerade traffic whose source address is within the netmask associated with the virtual network in question Problem: The FORWARD rule is too generic, forwarding traffic to/from the virtual network regardless of whether the dest/src IP address is within the netmask associated with the virtual network. Assuming the first problem is setup to only masquerade valid IP addresses from the virtual network, this rule would then allow guests to spoof their IP and have it forwarded off-host. Solution: Only forward packets whose IP address is within the netmask associated with the virtual network Problem: The policy of the FORWARD rule is ACCEPT, and/or later user defined rules may inadvertently match on traffic from the virtual network, again allowing through spoof traffic, or traffic from what should be an isolated virtual network Solution: There needs to be a catch-all REJECT rule associated with every bridge device, in both directions Problem: There is an extra physdev match per bridge device, and per guest device. This is basically unneccessary since the previous rule sets will already have allowed through the traffic. The physdev matches also only work if net.bridge.bridge-nf-call-iptables = 1 Solution: Simply remove the per-device matches Problem: The POSTROUTING rule has a physdev match applied, which only works if net.bridge.bridge-nf-call-iptables = 1. Solution: Remove physdev match & masquerade based on network address associated with the virtual network If we apply all solution outlined here, we'll end up with a set of rules which look like this.......... Type 1: Isolated virtual network -------------------------------- Chain POSTROUTING (policy ACCEPT 273 packets, 26341 bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 29 packets, 2244 bytes) pkts bytes target prot opt in out source destination 0 0 REJECT all -- * vnet2 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable 0 0 REJECT all -- vnet2 * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable Chain INPUT (policy ACCEPT 76724 packets, 366M bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT udp -- vnet2 * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 0 0 ACCEPT tcp -- vnet2 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 0 0 ACCEPT udp -- vnet2 * 0.0.0.0/0 0.0.0.0/0 udp dpt:67 0 0 ACCEPT tcp -- vnet2 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:67 Type 2: Forwarding to a specific NIC only ----------------------------------------- Chain POSTROUTING (policy ACCEPT 273 packets, 26341 bytes) pkts bytes target prot opt in out source destination 0 0 MASQUERADE all -- * eth1 192.168.200.0/24 0.0.0.0/0 Chain FORWARD (policy ACCEPT 29 packets, 2244 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- eth1 vnet3 0.0.0.0/0 192.168.200.0/24 state RELATED,ESTABLISHED 0 0 ACCEPT all -- vnet3 eth1 192.168.200.0/24 0.0.0.0/0 0 0 REJECT all -- * vnet3 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable 0 0 REJECT all -- vnet3 * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable Chain INPUT (policy ACCEPT 76724 packets, 366M bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT udp -- vnet3 * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 0 0 ACCEPT tcp -- vnet3 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 0 0 ACCEPT udp -- vnet3 * 0.0.0.0/0 0.0.0.0/0 udp dpt:67 0 0 ACCEPT tcp -- vnet3 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:67 Type 3: Forwarding to any active NIC ------------------------------------ Chain POSTROUTING (policy ACCEPT 273 packets, 26341 bytes) pkts bytes target prot opt in out source destination 16 1292 MASQUERADE all -- * * 192.168.122.0/24 0.0.0.0/0 Chain FORWARD (policy ACCEPT 29 packets, 2244 bytes) pkts bytes target prot opt in out source destination 44 20200 ACCEPT all -- * virbr0 0.0.0.0/0 192.168.122.0/24 state RELATED,ESTABLISHED 56 3676 ACCEPT all -- virbr0 * 192.168.122.0/24 0.0.0.0/0 0 0 REJECT all -- * virbr0 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable 0 0 REJECT all -- virbr0 * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable Chain INPUT (policy ACCEPT 76724 packets, 366M bytes) pkts bytes target prot opt in out source destination 28 1728 ACCEPT udp -- virbr0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 0 0 ACCEPT tcp -- virbr0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 5 1640 ACCEPT udp -- virbr0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:67 0 0 ACCEPT tcp -- virbr0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:67 So in summary: - Every single network type has the 4 INPUT rules for DHCP/DNS - Every single network type has catch all REJECT rules in FORWARD chain for both directions of traffic - A network forwarding to any device, has ACCEPT rules which allow through traffic associated with the virtual network IP range to/from any device - A network forwarding to a specific device, has ACCEPT rules which allow through traffic associated with the virtual network IP range to/from that specific device. - A network forwarding to any device, has MASQUERADE rule to translate source address which matches the virtual network & destined for any dev - A network forwarding to a specific device, has MASQUERADE rule to translate source address which matches the virutal network & destinaed for that specific device - There are no physdev matches needed. Hopefully at least one person has read this far through the email and still understands what is going on.... I'm attaching a patch which implements all this. BTW, there is also a bug in the vif-bridge script for Xen which adds a per-guest VIF physdev match rule. This needs to be removed too. 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 -=|

4 12

[Libvir] [PATCH] Remote patch, 2007-04-04
by Richard W.M. Jones 04 Apr '07

04 Apr '07

This is a version of the remote patch -- I'm going to call it "oldremote" because it includes the SunRPC code which we agreed to drop in favour of just using XDR (see [1]). So this patch is just posted here for public record. It applies against the latest CVS. Rich. [1] https://www.redhat.com/archives/libvir-list/2007-March/thread.html#00333 -- 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] Unified Xen patch (third and hopefully final version)
by Richard W.M. Jones 04 Apr '07

04 Apr '07

This is the third version of the unified Xen driver patch[1]. It includes Dan's fixes[2] and a minor fix of my own to fix compiles --without-xen. I've checked this and I'm happy with proposing it for inclusion in libvirt. Rich. [1] https://www.redhat.com/archives/libvir-list/2007-March/thread.html#00409 [2] https://www.redhat.com/archives/libvir-list/2007-April/msg00007.html -- 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)

3 3

[Libvir] [PATCH] Fix substitution of QEMUD_PID_FILE
by Richard W.M. Jones 04 Apr '07

04 Apr '07

This fixes the bug I raised in my previous email. Use AC_SUBST instead of AC_DEFINE because we want autoconf to substitute the value into the Makefile, not into config.h. Then add @QEMUD_PID_FILE@ to CFLAGS. This seems to be the correct thing to do, according to my understanding of http://tinyurl.com/34gtdj . 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)

2 4

[Libvir] xend_internal reads in bytes?
by Richard W.M. Jones 03 Apr '07

03 Apr '07

[Just an observation here - I'm busy with something else but may be able to take a closer look at this later.] Not only does xend_internal open a new connection for every HTTP request it makes, but it also reads the headers in as single bytes (but the body as a whole, presumably once it has Content-Length): connect(15, {sa_family=AF_FILE, path="/var/lib/xend/xend-socket"}, 27) = 0 write(15, "GET ", 4) = 4 write(15, "/xend/node/", 11) = 11 write(15, " HTTP/1.1\r\n", 11) = 11 write(15, "Host: localhost:8000\r\nAccept-Enc"..., 100) = 100 read(15, "H", 1) = 1 read(15, "T", 1) = 1 read(15, "T", 1) = 1 read(15, "P", 1) = 1 read(15, "/", 1) = 1 read(15, "1", 1) = 1 read(15, ".", 1) = 1 read(15, "1", 1) = 1 read(15, " ", 1) = 1 read(15, "2", 1) = 1 read(15, "0", 1) = 1 read(15, "0", 1) = 1 read(15, " ", 1) = 1 read(15, "O", 1) = 1 read(15, "K", 1) = 1 read(15, "\r", 1) = 1 read(15, "\n", 1) = 1 read(15, "C", 1) = 1 read(15, "o", 1) = 1 read(15, "n", 1) = 1 read(15, "t", 1) = 1 [...] read(15, "\n", 1) = 1 read(15, "\r", 1) = 1 read(15, "\n", 1) = 1 read(15, "(node (system Linux) (host oiras"..., 747) = 747 close(15) = 0 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)

2 1

[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