- Devel - libvirt List Archives

[Libvir] [PATCH] output virsh log to file
by Nobuhiro Itou 07 Jun '07

07 Jun '07

Hi, I made the patch which output debug messages and error messages of virsh to the log file. I think that it is necessary to leave logs to the file for the investigation at the failure. Debug messages can take appointed optional information, and error messages will make it easy to specify a cause. Moreover, I'm thinking about outputting virterror information to the virsh log file by the next step. It is simple specifications as follows. * Destination -- <USER HOME>/.virsh/virsh.log * Log size -- 1MB(1024*1024) * Number of Rotations -- 5 * There is process exclusion. First, will you take in this patch ? And, I have a plan to enhance logging functionality. (for example, libvirt error logging) Signed-off-by: Nobuhiro Itou <fj0873gn(a)aa.jp.fujitsu.com> Thanks, Nobuhiro Itou.

6 18

[Libvir] [PATCH] Cut out "type=ioemu" on Xen3.1
by Saori Fukuta 07 Jun '07

07 Jun '07

Hi, The definition of (type ioemu) is *not* required by Xen3.1. So I cut out it when xendConfigVersion is 4 or later. Signed-off-by: Saori Fukuta <fukuta.saori(a)jp.fujitsu.com> Thanks, Saori Fukuta. Index: xml.c =================================================================== RCS file: /data/cvs/libvirt/src/xml.c,v retrieving revision 1.73 diff -u -p -r1.73 xml.c --- xml.c 23 Apr 2007 07:41:23 -0000 1.73 +++ xml.c 31 May 2007 07:02:01 -0000 @@ -1047,6 +1047,7 @@ virDomainParseXMLDiskDesc(virConnectPtr * @conn: pointer to the hypervisor connection * @node: node containing the interface description * @buf: a buffer for the result S-Expr + * @xendConfigVersion: xend configuration file format * * Parse the one interface the XML description and add it to the S-Expr in buf * This is a temporary interface as the S-Expr interface @@ -1056,7 +1057,7 @@ virDomainParseXMLDiskDesc(virConnectPtr * Returns 0 in case of success, -1 in case of error. */ static int -virDomainParseXMLIfDesc(virConnectPtr conn ATTRIBUTE_UNUSED, xmlNodePtr node, virBufferPtr buf, int hvm) +virDomainParseXMLIfDesc(virConnectPtr conn ATTRIBUTE_UNUSED, xmlNodePtr node, virBufferPtr buf, int hvm, int xendConfigVersion) { xmlNodePtr cur; xmlChar *type = NULL; @@ -1129,7 +1130,8 @@ virDomainParseXMLIfDesc(virConnectPtr co virBufferVSprintf(buf, "(script '%s')", script); if (ip != NULL) virBufferVSprintf(buf, "(ip '%s')", ip); - if (hvm) + /* HVM type ioemu config for xen < 3.1 */ + if (hvm && xendConfigVersion < 4) virBufferAdd(buf, "(type ioemu)", 12); virBufferAdd(buf, ")", 1); @@ -1335,7 +1337,7 @@ virDomainParseXMLDesc(virConnectPtr conn if (nb_nodes > 0) { for (i = 0; i < nb_nodes; i++) { virBufferAdd(&buf, "(device ", 8); - res = virDomainParseXMLIfDesc(conn, nodes[i], &buf, hvm); + res = virDomainParseXMLIfDesc(conn, nodes[i], &buf, hvm, xendConfigVersion); if (res != 0) { free(nodes); goto error; @@ -1494,7 +1496,7 @@ virParseXMLDevice(virConnectPtr conn, ch goto error; } else if (xmlStrEqual(node->name, BAD_CAST "interface")) { - if (virDomainParseXMLIfDesc(conn, node, &buf, hvm) != 0) + if (virDomainParseXMLIfDesc(conn, node, &buf, hvm, xendConfigVersion) != 0) goto error; } cleanup:

3 6

[Libvir] Add scheduler patch?
by Atsushi SAKAI 06 Jun '07

06 Jun '07

Hi, Is there any plan to apply scheduler controller patch? https://www.redhat.com/archives/libvir-list/2007-May/msg00291.html https://www.redhat.com/archives/libvir-list/2007-May/msg00295.html Thanks Atsushi SAKAI

2 12

[Libvir] [PATCH] make xen compile -Werror and without PROXY turned on (the autobuild config)
by Hugh Brock 05 Jun '07

05 Jun '07

$SUBJECT says it all... --Hugh -- Red Hat Virtualization Group http://redhat.com/virtualization Hugh Brock | virt-manager http://virt-manager.org hbrock(a)redhat.com | virtualization library http://libvirt.org

2 1

Re: [Libvir] [PATCH] add scheduler API(take 3?)
by Richard W.M. Jones 04 Jun '07

04 Jun '07

+char * +virDomainGetSchedulerType(virDomainPtr domain, int *nparams) +{ + virConnectPtr conn; + char *schedtype; + + if (domain == NULL) { + TODO + return NULL; + } Is this case an error, or were you thinking of adding more semantics later on here? (and the same comment for virDomainGet/SetSchedulerParameters) +static int +cmdSchedinfo(vshControl * ctl, vshCmd * cmd) +{ [...] + char *str_weight = strdup("weight"); + char *str_cap = strdup("cap"); + + nparams = malloc(sizeof(int)); + *nparams = 0; + + if (!vshConnectionUsability(ctl, ctl->conn, TRUE)) + return FALSE; There's still a problem memory leak here. + /* Currently supports Xen Credit only */ + weight = vshCommandOptInt(cmd, "weight", &weightfound); + if(weightfound){ inputparam++; } + + cap = vshCommandOptInt(cmd, "cap", &capfound); + if(capfound){ inputparam++; } and can this be made so it isn't Xen-specific? + if ((domain == NULL) || (domain->conn == NULL)) + return -1; + + priv = (xenUnifiedPrivatePtr) domain->conn->privateData; + if (priv->handle < 0 || domain->id < 0) + return -1; At the lowest level, these functions should return error messages back to the upper layers. Otherwise users have nothing to diagnose errors with. + /* + * Support only dom_interface_version >=5 + * (Xen3.1.0 or later) + */ + if (dom_interface_version < 5) + return -1; Is this because earlier hypervisors didn't support this, or is it just not implemented? Rich.

3 7

[Libvir] [PATCH] Fix strange error message in virsh attach-device
by Masayuki Sunou 04 Jun '07

04 Jun '07

Hi Now, virsh attach-device displays the following messages when "device" attribute of "disk" element is "floppy" in XML. # virsh attach-device HVM_RH4_file floppy.xml libvir: Xen Daemon error : POST operation failed: (xend.err 'Invalid Configuration: XendConfig: @\x14\xce not a valid device type') error: Failed to attach device from floppy.xml This patch fixes this strange error message displaying "@\x14\xce". Description of this patch VirDomainParseXMLDiskDesc() returns 0 without putting data in virBuffer, when "floppy" is set. Therefore, virParseXMLDevice() returns no initialized data, and xenDaemonAttachDevice() passes Xen this data. Because virDomainParseXMLDesc() works wrong when this patch changes return value of VirDomainParseXMLDiskDesc(),this patch fixes virParseXMLDevice() as follows. - Initialize data - Return error if data does not change. As a result, xenDaemonAttachDevice() doesn't pass strange data to Xen, and Xen doesn't return strange error message. Signed-off-by: Masayuki Sunou <fj1826dm(a)aa.jp.fujitsu.com> Thanks, Masayuki Sunou. ---------------------------------------------------------------------- Index: src/xml.c =================================================================== RCS file: /data/cvs/libvirt/src/xml.c,v retrieving revision 1.73 diff -u -p -r1.73 xml.c --- src/xml.c 23 Apr 2007 07:41:23 -0000 1.73 +++ src/xml.c 25 May 2007 09:46:56 -0000 @@ -1481,6 +1481,7 @@ virParseXMLDevice(virConnectPtr conn, ch return (NULL); buf.size = 1000; buf.use = 0; + memset(buf.content, 0, (size_t)buf.size); xml = xmlReadDoc((const xmlChar *) xmldesc, "domain.xml", NULL, XML_PARSE_NOENT | XML_PARSE_NONET | XML_PARSE_NOERROR | XML_PARSE_NOWARNING); @@ -1492,6 +1493,9 @@ virParseXMLDevice(virConnectPtr conn, ch if (xmlStrEqual(node->name, BAD_CAST "disk")) { if (virDomainParseXMLDiskDesc(conn, node, &buf, hvm, xendConfigVersion) != 0) goto error; + /* SXP is not created when device is "floppy". */ + else if (!strlen(buf.content)) + goto error; } else if (xmlStrEqual(node->name, BAD_CAST "interface")) { if (virDomainParseXMLIfDesc(conn, node, &buf, hvm) != 0) ----------------------------------------------------------------------

2 5

[Libvir] Use virsh to monitor qemud
by Fabian Deutsch 03 Jun '07

03 Jun '07

Hey, I jsut installed Fedora 7 and tried to install some guests and it worked like a charm. I use qemu for full virtulization. A couple of minutes later i stumbled across libvirts virtsh. But now I wonder how I cna use virtsh to connect to qemud - all I get is something like: "Can't connect to hyperisor." - fabiand

3 4

[Libvir] SOLVED Re: cannot use vncviewer and VMM graphics console to access HVM guest on RHES 5
by Glen Deem 03 Jun '07

03 Jun '07

Thanks to Igor Chubin (spasibo) and Richard Jones, the qemu vnc server was listening but I did not connect to its proper port (why libvirt doesn't use <IP>:<domU id> kind of vnc connection and restricts the server to local host only by default?). Regards, Glen On 5/31/07, Glen Deem <xen.inbox@XXXXXXXXX> wrote: > Hi all, > > I've created an HVM guest under RHES 5 (Xen 3.0.3) using "xm create" > but I cannot access it with vncviewer. > > The Virtual Machine Manager also informs about graphics console unavailability. > > What am I doing wrong, please? > > I do > > vncviewer 123.456.789.123:4, > where 4 is the guest id. > > This is the xm config file is: > > name = "hvmGuest" > builder = "hvm" > memory = "500" > disk = [ 'file:/var/lib/red-hat.img,hda,w', ] > vif = [ 'type=ioemu, mac=00:16:3e:34:3b:ba, bridge=xenbr0', ] > device_model = "/usr/lib/xen/bin/qemu-dm" > kernel = "/usr/lib/xen/boot/hvmloader" > vnc=1 > vncunused=1 > apic=1 > acpi=1 > pae=1 > vcpus=1 > serial = "pty" > on_reboot = 'restart' > on_crash = 'restart' > > Thanks a lot in advance. > > Glen from Ottawa, Canada >

4 4

[Libvir] Re: [Xen-users] SOLVED Re: cannot use vncviewer and VMM graphics console to access HVM guest on RHES 5
by Glen Deem 01 Jun '07

01 Jun '07

Hi Dan, I'm with you about the VNC authentication. But I still don't understand the logic behind assigning HVM displays. Instead of clear "domU ID is the display number" (vncunused 0), the Virtual Machine Manager assigns vncunused to 1 and then calculates the 5900+ port, I suppose depending on what port is not occupied (BTW where exactly is this code in the source, please?). Why is that? And how am I suppose to find out what that port number is if I'd want to connect to a VMM-created vm manually with my vnc client? Thanks, Glen Daniel P. Berrange wrote: > On Fri, Jun 01, 2007 at 11:03:36AM -0400, Glen Deem wrote: >> Thanks to Igor Chubin (spasibo) and Richard Jones, the qemu vnc server >> was listening but I did not connect to its proper port (why libvirt >> doesn't use <IP>:<domU id> kind of vnc connection and restricts the >> server to local host only by default?). > > VNC authentication is an utter joke. It can be trivially brute forced > so exposing it on a public IP address is not a good idea, hence the > default is 127.0.0.1, though even that's not ideal because it is still > exposed to local users. Ultimately VNC needs to have SSL/TLS support > integrated into it to allow secure access over public network, which > is something I'm working on for QEMU... > > Dan.

2 1

[Libvir] cannot use vncviewer and VMM graphics console to access HVM guest on RHES 5
by Glen Deem 01 Jun '07

01 Jun '07

Hi all, I've created an HVM guest under RHES 5 (Xen 3.0.3) using "xm create" but I cannot access it with vncviewer. The Virtual Machine Manager also informs about graphics console unavailability. What am I doing wrong, please? I do > vncviewer 123.456.789.123:4, where 4 is the guest id. This is the xm config file is: name = "hvmGuest" builder = "hvm" memory = "500" disk = [ 'file:/var/lib/red-hat.img,hda,w', ] vif = [ 'type=ioemu, mac=00:16:3e:34:3b:ba, bridge=xenbr0', ] device_model = "/usr/lib/xen/bin/qemu-dm" kernel = "/usr/lib/xen/boot/hvmloader" vnc=1 vncunused=1 apic=1 acpi=1 pae=1 vcpus=1 serial = "pty" on_reboot = 'restart' on_crash = 'restart' Thanks a lot in advance. Glen from Ottawa, Canada

3 2

Re: [Libvir] Debian package structure
by Marco Sinhoreli 31 May '07

31 May '07

On 5/30/07, Richard W.M. Jones <rjones(a)redhat.com> wrote: > > Marco Sinhoreli wrote: > > hello all, > > > > I have been worked in libvirt, virt-manager and virtinst packages to > > Debian for a weeks. Packages are now stabilized. Following below the > > /debian directories structure for analise. > > * libvirt: > > svn co http://svn.mussicorp.net/projetos/src/xen/libvirt/trunk/ > > In debian/rules you shouldn't need this any longer (with latest CVS): > > export CFLAGS += -fno-stack-protector I know it is fixed for libvirt, but it is nedded to fix virt-manager too. That's why I keep it in this package. > * Virt-manager: > > svn co > > > http://svn.mussicorp.net/projetos/src/xen/virt-manager/virt-manager/trunk/ > > Shouldn't virt-manager Depends: on python-libvirt and virtinst? My fault. I'll fix it. It should probably Build-Depends: on (eg) cdbs too, since firstly you're > using cdbs in debian/rules, and secondly virt-manager isn't pure Python > - it contains a C-based widget. okay. I'll pay attention on that. Not clear what the postrm was for. Is there configuration kept in > /usr/share/virt-manager? My fault. I'll checked it. Thanks

1 0

[Libvir] Debian package structure
by Marco Sinhoreli 30 May '07

30 May '07

hello all, I have been worked in libvirt, virt-manager and virtinst packages to Debian for a weeks. Packages are now stabilized. Following below the /debian directories structure for analise. * libvirt: svn co http://svn.mussicorp.net/projetos/src/xen/libvirt/trunk/ * Virt-manager: svn co http://svn.mussicorp.net/projetos/src/xen/virt-manager/virt-manager/trunk/ * Virtinst: svn co http://svn.mussicorp.net/projetos/src/xen/virt-manager/virtinst/trunk/ Best regards, -- Marco Sinhoreli

2 1

Re: [Libvir] Error while run make: undefined reference to `xenHypervisorMakeCapabilitiesXML'
by Marco Sinhoreli 30 May '07

30 May '07

Thanks, I had a problem with my libxen package. The /usr/lib/libxenstore.so wasn't linked to /usr/lib/libxenstore.so.3.0.0. Regards, > > On 5/29/07, Daniel Veillard <veillard(a)redhat.com> wrote: > > > > On Mon, May 28, 2007 at 11:26:18AM -0400, Daniel Veillard wrote: > > > On Mon, May 28, 2007 at 12:15:31PM -0300, Marco Sinhoreli wrote: > > > > Hello list, > > > > > > > > I'm with this error while I am compiling the libvirt: > > > > > > > > xencapstest.o: In function `testCompareFiles': > > > > /usr/src/libvirt/tests/xencapstest.c:33: undefined reference to > > > > `xenHypervisorMakeCapabilitiesXML' > > > > collect2: ld returned 1 exit status > > > > > > > > Any idea? > > > > > > What version ? I guess it comes when compiling on a machine where > > > Xen developments environment is not present, this ought to be fixed > > > if not already in CVS, > > > > actually I can reproduce that to on CVs head, will fix ! > > > > 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/ > > > > > > -- > Marco Sinhoreli -- Marco Sinhoreli

1 0

Re: [Libvir] Finally - fix the build on Debian
by Marco Sinhoreli 30 May '07

30 May '07

Hello, I compiled the libvirt from last cvs source without to export CFLAGS -fstack-protector option without problem. After it, I compiled the virt-manger and it isn't working. Running virt-manager retur this error: virt-manager Traceback (most recent call last): File "/usr/share/virt-manager/virt-manager.py", line 104, in ? from virtManager.config import vmmConfig File "/usr/share/virt-manager/virtManager/config.py", line 24, in ? import libvirt File "/usr/lib/python2.4/site-packages/libvirt.py", line 7, in ? import libvirtmod ImportError: /usr/lib/libvirt.so.0: undefined symbol: __stack_chk_guard Also is necessáry correction in virt-manager code? regards, On 5/29/07, Richard W.M. Jones <rjones(a)redhat.com> wrote: > > > Daniel Veillard wrote: > > > On Tue, May 29, 2007 at 03:21:48PM +0100, Richard W.M. Jones wrote: > > >> The attached patch fixes three separate build problems on Debian: > > >> > > >> (1) The libtool autoconf macro is wrong in that it requires a C++ > > >> compiler and /lib/cpp, neither of which seems to be really needed. > > >> > > >> (2) If you pass -fstack-protector while compiling, then you also need > > to > > >> pass it while linking, so that gcc knows to link -lssp. > > >> > > >> (3) Long-standing problem that xencapstest.c won't compile > > --without-xen. > > >> > > >> Well, OK so I didn't actually fix (1), but I did add a note to the > > TODO > > >> file pointing out the problem. So you'll still need to install the > > >> Debian "g++" package before you can compile libvirt. > > > > > > None of this is actually Debian specific, it actually affects various > > setups. > > > Patch looks fine to me, > > > > Committed. > > > > Rich. > > > > -- > > Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/<http://et.redhat.com/%7Erjones/> > > 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 > > > > -- > > Libvir-list mailing list > > Libvir-list(a)redhat.com > > https://www.redhat.com/mailman/listinfo/libvir-list > > > > > > > > > -- > Marco Sinhoreli -- Marco Sinhoreli

1 0

[Libvir] Finally - fix the build on Debian
by Richard W.M. Jones 29 May '07

29 May '07

The attached patch fixes three separate build problems on Debian: (1) The libtool autoconf macro is wrong in that it requires a C++ compiler and /lib/cpp, neither of which seems to be really needed. (2) If you pass -fstack-protector while compiling, then you also need to pass it while linking, so that gcc knows to link -lssp. (3) Long-standing problem that xencapstest.c won't compile --without-xen. Well, OK so I didn't actually fix (1), but I did add a note to the TODO file pointing out the problem. So you'll still need to install the Debian "g++" package before you can compile libvirt. 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] Error while run make: undefined reference to `xenHypervisorMakeCapabilitiesXML'
by Marco Sinhoreli 29 May '07

29 May '07

Hello list, I'm with this error while I am compiling the libvirt: xencapstest.o: In function `testCompareFiles': /usr/src/libvirt/tests/xencapstest.c:33: undefined reference to `xenHypervisorMakeCapabilitiesXML' collect2: ld returned 1 exit status Any idea? Regards. -- Marco Sinhoreli

2 2

[Libvir] [PATCH] Fix some memory leak
by Masayuki Sunou 29 May '07

29 May '07

Hi This patch fixes some memory leak in libvirt. 1. The point that checks command-option in virsh.c 2. The point that checks version of Xen in xen_internal.c 3. The point that checks OS type of VM in xend_internal.c And these memory leaks can be checked by valgrind. Signed-off-by: Masayuki Sunou <fj1826dm(a)aa.jp.fujitsu.com> Thanks, Masayuki Sunou. ------------------------------------------------------------------------------- Index: src/virsh.c =================================================================== RCS file: /data/cvs/libvirt/src/virsh.c,v retrieving revision 1.76 diff -u -p -r1.76 virsh.c --- src/virsh.c 23 May 2007 15:09:19 -0000 1.76 +++ src/virsh.c 29 May 2007 07:43:48 -0000 @@ -3153,8 +3153,10 @@ vshCommandParse(vshControl * ctl, char * c->def = cmd; c->next = NULL; - if (!vshCommandCheckOpts(ctl, c)) + if (!vshCommandCheckOpts(ctl, c)) { + if(c) free(c); goto syntaxError; + } if (!ctl->cmd) ctl->cmd = c; Index: src/xen_internal.c =================================================================== RCS file: /data/cvs/libvirt/src/xen_internal.c,v retrieving revision 1.72 diff -u -p -r1.72 xen_internal.c --- src/xen_internal.c 30 Apr 2007 17:30:11 -0000 1.72 +++ src/xen_internal.c 29 May 2007 07:43:48 -0000 @@ -1497,11 +1497,15 @@ xenHypervisorInit(void) virXenError(VIR_ERR_XEN_CALL, " ioctl ", IOCTL_PRIVCMD_HYPERCALL); close(fd); in_init = 0; + if (ipt) + free(ipt); return(-1); done: close(fd); in_init = 0; + if (ipt) + free(ipt); return(0); } Index: src/xend_internal.c =================================================================== RCS file: /data/cvs/libvirt/src/xend_internal.c,v retrieving revision 1.114 diff -u -p -r1.114 xend_internal.c --- src/xend_internal.c 11 May 2007 14:21:28 -0000 1.114 +++ src/xend_internal.c 29 May 2007 07:43:49 -0000 @@ -3072,7 +3072,7 @@ xenDaemonCreateLinux(virConnectPtr conn, static int xenDaemonAttachDevice(virDomainPtr domain, char *xml) { - char *sexpr, *conf; + char *sexpr, *conf, *str; int hvm = 0, ret; xenUnifiedPrivatePtr priv; @@ -3084,8 +3084,11 @@ xenDaemonAttachDevice(virDomainPtr domai priv = (xenUnifiedPrivatePtr) domain->conn->privateData; - if (strcmp(virDomainGetOSType(domain), "linux")) + str = virDomainGetOSType(domain); + if (strcmp(str, "linux")) hvm = 1; + if (str) + free(str); sexpr = virParseXMLDevice(domain->conn, xml, hvm, priv->xendConfigVersion); if (sexpr == NULL) return (-1); -------------------------------------------------------------------------------

2 1

[Libvir] [PATCH] add scheduler API(take 3?)
by Atsushi SAKAI 29 May '07

29 May '07

Hi, This patch is retry from one-month ago. This patch is for fixes following suggestions. https://www.redhat.com/archives/libvir-list/2007-April/msg00090.html And I add Check Xen3.1.0 only. (As you know domctl on Xen3.0.4 does not work fine.) How to use is described in following mail. https://www.redhat.com/archives/libvir-list/2007-April/msg00050.html Signed-off-by: Atsushi SAKAI <sakaia(a)jp.fujitsu.com> Thanks Atsushi SAKAI

5 7

[Libvir] [PATCH] Add Python binding for virGetVersion
by Richard W.M. Jones 29 May '07

29 May '07

This patch adds a Python binding for the virGetVersion call (called libvirt.getVersion). $ python Python 2.4.4 (#1, Oct 23 2006, 13:58:18) [GCC 4.1.1 20061011 (Red Hat 4.1.1-30)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import libvirt; >>> libvirt.getVersion (None); (2002, 3000001) >>> libvirt.getVersion ("QEMU"); (2002, 2002) It also gives you a way to detect if a particular driver is compiled in, which I guess could be quite useful: >>> libvirt.getVersion ("not_here"); libvir: error : no support for hypervisor Traceback (most recent call last): File "<stdin>", line 1, in ? File "/home/rjones/local/lib/python2.4/site-packages/libvirt.py", line 95, in getVersion if ret is None: raise libvirtError ("virGetVersion() failed") libvirt.libvirtError: virGetVersion() failed no support for hypervisor 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: Create a logfile for each QEMU vm
by Daniel P. Berrange 29 May '07

29 May '07

Most of the error reporting the QEMU daemon is focused on sending errors wrt to RPC ops to the client. There is no provision currently for getting info about the QEMU vm itself when problems occur. The most common problem is some mis-configurable in the XML causes qemu to fail to start up. This results in the completely accurate & completely useless (mea-culpa) error message libvirt.libvirtError: virDomainCreateLinux() failed internal error End-of-file while reading PTY startup output' What this means is that qemu crashed/exited at startup. Now this patch does not (yet) directly address that stupid error message, but what it does do is provide a way to diagnose the real problem. For every VM we start it will create a logfile /etc/libvirt/qemu/logs/[vmname].log Or $HOME/.libvirt/qemu/logs/[vmname].log And all output from QEMU's stderr/stdout will get written to this file. So # virsh --connect qemu:///system start wizz libvir: QEMU error : internal error End-of-file while reading PTY startup output error: Failed to start domain wizz # cat /etc/libvirt/qemu/logs/wizz.log qemu: could not open hard disk image '/home/berrange/src/xen/virtinst--devel/demo' Next up I'm going to work on a) Improving the error message b) Adding validation that disk images actually exist before launching QEMU since that's the most common error we're seeing 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 -=|

6 9

[Libvir] AC_PROG_CPP
by Richard W.M. Jones 29 May '07

29 May '07

We have AC_PROG_CPP, but apparently no C++ code? In any case unless a C++ compiler is installed, I get: checking whether we are using the GNU C++ compiler... no checking whether g++ accepts -g... no checking dependency style of g++... none checking how to run the C++ preprocessor... /lib/cpp configure: error: C++ preprocessor "/lib/cpp" fails sanity check See `config.log' for more details. 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] Question on acquiring cpuTime in struct _virDomainInfo
by Jan Michael 29 May '07

29 May '07

Hi everyone, using libvirt I'm trying to calculate cpu utilization of a node in percent. But sometimes values beyond 100.0% are being calculated. This is because a domain spend more time on a cpu than time is elapsed in the meantime. A short explanation of the way how cpu utilization is computed in my case: 1. - open two connections with conn_cur/conn_old = virConnectOpenReadOnly(NULL); 2. - get current time gettimeofday(&time_old, NULL); - get domain by id with dom_old = virDomainLookupByID(conn_old, id) - get domain information virDomainGetInfo(dom_old, &info_old); 3. - sleep a second 4. - doing same stuff like in 2. but with _cur 5. - compute cpu utilization by dividing used cputime by elapsed time and multiply with 100 Am I right if I suppose that cpuTime for _virDomainInfo structure will be directly acquired from the hypervisor in virDomainGetInfo (dom_old, &info_old) or is it already present with getting the domain itself? Is there any better solution of doing this, which is more precise? And another general question: The monitoring utility of xen, called xentop, provides also statistics about networking and vbds. Are there any plans to provide this values by libvirt in the future? Cheers, Jan

3 5

[Libvir] Please check my autoconf libvirt.m4
by Richard W.M. Jones 24 May '07

24 May '07

Attached is an autoconf snippet which allows you to check that the libvirt library is installed (not necessarily development headers though) and check the version number. If any autoconf experts (hello, Mark) would like to check it makes sense, that'd be great. 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

4 7

[Libvir] Remote patch, 2007-05-22
by Richard W.M. Jones 22 May '07

22 May '07

This is the latest version of the remote patch. http://annexia.org/tmp/libvirt-remote-20070522.patch I'd like to propose this for merging. The only differences are those described here: https://www.redhat.com/archives/libvir-list/2007-May/msg00156.html, and a bit more testing. 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 22 May '07

22 May '07

Shuveb Hussain wrote: >> There is the same problem with the Xen libraries. Dan had to rewrite a >> lot of code concerning access to the hypervisor. > > No matter how different I think, the end result looks just like the > OpenVZ library code :-P > So, I'm trying to write code that looks different, but does the same > thing. The OpenVZ utilities are however, scripting friendly. Their > text output is consistent. How about writing a daemon for OpenVZ that > "talks" to the OpenVZ utilities, rather than trying to re-write the > utilities? Would this be a bad idea? It sounds like a very good idea. There can also be no question of infringement if done this way. > The actual libvirt can then > connect to this daemon to get the real stuff done. This is what I did > in my EasyVZ GUI tool for OpenVZ. Why is the daemon needed though? The libvirt calls can just launch the OpenVZ command line tools as necessary. We got into daemons with QEMU, and it's nothing but trouble. 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

[Libvir] Re: [Fedora-xen] BUG at arch/x86_64/mm/../../i386/mm/hypervisor.c:185!
by Richard W.M. Jones 22 May '07

22 May '07

Naoki wrote: > On Mon, 2007-05-21 at 18:53 +0100, Richard W.M. Jones wrote: >> I've been stressing Xen all week, and found plenty of bugs but not this >> one. Can I ask a few questions about your set-up? > > Fire away.. > >> - Is this dmesg in the dom0 or the domU (guest)? > > dom0 > >> - You seem to have an x86-64 SMP kernel. Can you provide details of >> the machine (how many cores, how much RAM, etc.) > > Single chip, dual core, intel Core 2 Duo. > > Family: Pentium 4 > Manufacturer: Intel > ID: 47 0F 00 00 FF FB EB BF > Signature: Type 0, Family 15, Model 4, Stepping 7 > > >> - How many guests are you running, and of what sort. eg. What is the >> guest OS? Is it paravirt or full-virt? > > I had one inactive guest running. > dom0 is running x86_64 kernel 2.6.20-2925.8.fc7xen. > And I'm on rawhide fully updated. That's the same set-up I'm using. Do you get this problem often? Is it reproducible? Is there a particular thing that you are doing when this happens? 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] [RFC]OpenVZ XML def
by Shuveb Hussain 22 May '07

22 May '07

Hi, I am adding OpenVZ support to Libvirt and work is progressing well. I'm able to list VM instances and I'm slowly trying to cover the basic API functions one by one. That brings us to the creation of OpenVZ based VMs. Just wanted to discuss the basic XML definition format so that I can get comments and improve if need be: <domain type='openvz'> <name>openvzdemo</name> <uuid>55a2441d-e012-40fe-a4f7-78e176015d40</uuid> <vpsid>101</vpsid> <template>vps.basic</template> <onboot>true</onboot> <os template='slackware-10.2-i386-minimal'/> <network> <hostname>openvzhost</hostname> <ip address='192.168.1.101' netmask='255.255.255.0' defgw='192.168.1.1' /> <nameserver>192.168.1.1</nameserver> <nameserver>202.56.250.5</nameserver> </network> </domain> Does this look OK? Regards, -- Shuveb Hussain. EasyVZ - OpenVZ management GUI: http://easyvz.sourceforge.net I blog at http://binarykarma.org Spread the Karma.

4 15

[Libvir] [RFC] Life-cycle Management of the domain take2
by Saori Fukuta 22 May '07

22 May '07

Hi, I'm making a patch to provide a changing allocation dynamically and statically without keeping state at the library. And this is still uncompleted works, but I would like to hear your comments. Attached patch shows below: # virsh --help setmem NAME setmem - change memory allocation SYNOPSIS virsh setmem <domain> <kilobytes> [ --static | --dynamic ] DESCRIPTION Change the current memory allocation in the guest domain. OPTIONS <domain> domain name, id or uuid <kilobytes> number of kilobytes of memory --static static change --dynamic dynamic change First, I made upper interface. --- virsh.c ( attached file "add_option2virsh.patch ) - add 2 options as follows: --dynamic, --static - call new APIs: virDomainSetMaxMemory -> virDomainSetMaxMemoryScope virDomainSetMemory -> virDomainSetMemoryScope virDomainSetVcpus -> virDomainSetVcpusScope --- libvirt.c ( attached file "add_option2libvirt.patch ) - add 3 APIs: virDomainSetMaxMemoryScope virDomainSetMemoryScope virDomainSetVcpusScope and I will add lower driver as follows in the case of setmem. --- drivers ( attached file "add_option2driver.patch ) - xen_unified.c : add xenUnifiedDomainSetMemoryScope - xend_internal.c : add xenDaemonDomainSetMemoryScope - other : set NULL to domainSetMemoryScope I plan to achieve allocation dynamically and statically by such a way at xenDaemonDomainSetMemoryScope. 1. get configuration from the Xen Daemon using sexpr_get. 2. change the value when static option is specified, change the node of configuration using new API that I will make. when dynamic option is specified, change the allocation using xend_op 3. set configuration to the Xen Daemon using xend_op Why I did not use virDomainGetXMLDesc and virDomainDefineXML was some elements ware lost in current XML. For example, there is no "vncpasswd", "cpus", "localtime" in XML configuration with virDomainGetXMLDesc. So when I set the "vncpasswd" the "vncpasswd" will disappear after I define the XML configuration. How does this sound ? Thanks, Saori Fukuta.

4 18

[Libvir] QEMU without KVM
by Steven W. Moyer 17 May '07

17 May '07

I'm working on getting QEMU running with libvirt and virt-manager and have thus far had no success. I chose QEMU because it didn't require CPU support for full-virtualization (I got a bit older CPUs). Now I'm at a stand-still trying to get it running. My libvirt is compiled with QEMU support, but I'm getting a "virConnectOpenReadOnly() failed error when it tries to connect the the hypervisor. A couple questions: 1) How do I start qemu as a service? I actually have 6 guests running. 2) How do I connect from libvirt to qemu? (either running or not). Could someone who's already been there give me a little libvirt/qemu tutorial? Thanks, smoyer -- Steven W. Moyer Principle Architect, Assurance Applications C-COR Solutions, LLC 60 Decibel Road State College, PA 16801 Office Phone: 814-231-4408 Front Desk: 814-238-2461 Cell Phone: 814-883-0391 Fax: 814-278-6540 E-mail: smoyer(a)c-cor.com AIM: StevenWMoyer ICQ: 349680381 Jabber: smoyer1(a)jabber.jcware.org MSN: smoyer64 Yahoo: smoyer64

3 19

[Libvir] virsh - vcpuinfo cmd not working in 0.2.2
by Jan Michael 15 May '07

15 May '07

Cheers libvirt, I've tested the CLI virsh with my recent compiled version of libvirt and version 0.1.9. In Version 0.2.2 vcpuinfo provides wrong information. In version 0.1.9 only the values for VCPU and CPU are wrong. Do you have any idea why? See the test results below. Jan > xm vcpu-list Name ID VCPUs CPU State Time(s) CPU Affinity Domain-0 0 0 0 r-- 95463.9 any cpu Domain-0 0 1 - --p 55.6 any cpu stornode 6 0 1 -b- 2036.1 1 worknode 5 0 1 -b- 2073.9 1 > virsh vcpuinfo (0,5,6) in version 0.2.2 - Domain-0 VCPU: 0 CPU: 0 State: blocked CPU time: 0.0s CPU Affinity: -- - worknode virsh # vcpuinfo 5 VCPU: 0 CPU: 0 State: blocked CPU time: 4.3s CPU Affinity: -- - stornode VCPU: 0 CPU: 0 State: blocked CPU time: 4.3s CPU Affinity: -- > virsh vcpuinfo (0,5,6) in version 0.1.9 - Domain-0 VCPU: 0 CPU: 0 State: running CPU time: 95466.7s CPU Affinity: yy - worknode VCPU: 0 CPU: 1 State: blocked CPU time: 2074.2s CPU Affinity: -y - stornode VCPU: 0 CPU: 1 State: blocked CPU time: 2036.5s CPU Affinity: -y

4 13

[Libvir] Remote patch 20070514
by Richard W.M. Jones 15 May '07

15 May '07

This is the current remote patch, against current CVS: http://annexia.org/tmp/libvirt-remote-20070514.patch and a patch against the previous patch so you can see what changed (not very much): http://annexia.org/tmp/libvirt-remote-20070505-to-20070514.patch My To-Do list at the moment: (a) Disable Nagle (https://www.redhat.com/archives/libvir-list/2007-May/msg00142.html) (b) Implement Mark's sensible client certificate checks (https://www.redhat.com/archives/libvir-list/2007-May/msg00152.html) (c) Update TLS certificate documentation to reflect (b). And I'm hoping with those done we may be able to apply this one? It would be great if others could test 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

2 1

[Libvir] How libvirt handles QEMU?
by Jun Koi 14 May '07

14 May '07

Hello, I am new to libvirt, so have a question. My concern is: libvirt can manage QEMU VMs. The point is thatI QEMU doesnt not export monitor interface to outside (at least that is what I know about older version of QEMU, not sure if anything changed recently). So how can libvirt does something like: pause, resume or extract internal information about a QEMU VM? Thank you, Jun

2 1

[Libvir] [PATCH] Remote 0/8: Plan
by Richard W.M. Jones 14 May '07

14 May '07

Below is the plan for delivering the remote patch for review in stages. More details about in each email. I only expect to get through the first two emails today. Rich. 1 Additional error handling --------------------------- M include/libvirt/virterror.h M src/virterror.c 2 Client-server protocol ------------------------ A qemud/remote_protocol.x A qemud/rpcgen_fix.pl A qemud/remote_protocol.c A qemud/remote_protocol.h 3 Client-side ------------- A src/remote_internal.c A src/remote_internal.h M src/driver.h M src/libvirt.c 4 Server-side call dispatch --------------------------- A qemud/remote.c A qemud/remote_generate_stubs.pl A qemud/remote_dispatch_localvars.h A qemud/remote_dispatch_proc_switch.h A qemud/remote_dispatch_prototypes.h 5 Client-side QEMUD modifications --------------------------------- M src/qemu_internal.c 6 Server-side QEMUD modifications --------------------------------- A qemud/protocol.x A qemud/protocol.c M qemud/protocol.h M qemud/Makefile.am M qemud/conf.c M qemud/dispatch.c M qemud/dispatch.h M qemud/internal.h M qemud/qemud.c M qemud/uuid.c 7 Documentation updates ----------------------- M docs/libvir.html M docs/remote.html 8 Build system -------------- M .cvsignore M configure.in A libvirtd.conf M src/Makefile.am A RENAMES -- 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)

4 44

[Libvir] gl_COMPILER_FLAGS gives an error
by Richard W.M. Jones 14 May '07

14 May '07

./configure: line 21215: syntax error near unexpected token `-fprofile-arcs' ./configure: line 21215: ` gl_COMPILER_FLAGS(-fprofile-arcs)' The only solution I can seem to find is to comment out the calls to gl_COMPILER_FLAGS in configure.in. Can't very much on Google about what gl_COMPILER_FLAGS is supposed to do. 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 1

[Libvir] PATCH: Fix uninitialized variable & bridge setup
by Daniel P. Berrange 11 May '07

11 May '07

Two crazy bugs - I forgot an =0 initialization in a recent patch to deal with qemu startup - If you don't have any virtual networks defined, then libvirt_qemud will never called brctlInit() so trying to start a guest using bridged network will get EINVAL. 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] Three cleanup patches
by Richard W.M. Jones 11 May '07

11 May '07

* Add some extra generated files to .cvsignore * Remove an unused header in qemud/uuid.c * Log an error if xenHypervisorOpen fails because xenHypervisorInit has failed. 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)

3 4

[Libvir] Making QEMU use the real internal driver API
by Daniel P. Berrange 10 May '07

10 May '07

So currently, as we all know, the QEMU driver is just a shim through to the QEMU daemon. Looking at the code for Rich's remote driver I quite like the way the remote driver / server works like, and don't like the ugliness of having the special case QEMU code in there. We always had a long term plan to try & make the QEMU driver fit into the regular driver API more cleanly but not really tackled it yet. Similarly we've periodically brought up the idea of having asynchronous notifications of 'interesting' state changes in the drivers, to eliminate the need for polling. After a little thinking I have an idea that may let us address both issues in one go. Or to be more precise, put infrastructure in place to let us move closer to allowing async notiifcations. First let me consider the files under qemud/ .... Self-contained helper routines, ignore for rest of discussion bridge.c bridge.h iptables.c iptables.h uuid.c uuid.h buf.c buf.h The on the wire protcol definition, this is the bit we want to kill in favour of the generic remote wire protocol: protocol.h The code to convert from wire -> function calls. Again this ought to die in favour of the generic remote dispatcher. dispatch.c dispatch.h The QEMU config handling routines. conf.c conf.h The impl of core APIs: driver.c driver.h Finally the 'server': internal.h qemud.c The end-goal is that 'qemud/driver.c' would become 'src/qemu_internal.c' implementing the official internal driver API. The 'qemud/conf.c' would likely become 'src/qemu_config.c'. The key difference between the internal driver API, and the QEMU specific driver 'API' inside the daemon is the prescense of some global state via the 'qemud_server' struct. If we can figure out a way to store this state inside the regular driver API we can refactor that without much problem. Then there is the need for an event loop for monitoring the file handles of the QEMU processes, which at the moment is fairly tied into the event loop used to monitor the client/server socket handles. This existing code is rather ugly & has bad structure IMHO. The result is that code which ought to be isolated in driver.c, is instead part of qemud.c because of event loop integration. Finally, there is some code which runs on startup, and shutdown of the daemon, to do stuff like auto-start of VMs / networks, and clean shutdown of the same. Oh, and we need to make sure the QEMU driver is never activated locally, only when libvirt.so is being used as part of 'libvirtd'. So at a high level what I think we'd need to add to the internal driver API to make this possible is In driver.h: typedef int (*virDrvStartup)(void); typedef int (*virDrvShutdown)(void); Adding these to the 'virDriver' struct. Regular apps using libvirt.so would never trigger these APIs - they're only intended for the daemon, so I figure we'd have to private APIs in the libivrt.so (but not in the libvirt.h) __virStartup(void); __virShutdown(void); Since these are only called by the daemon, we now conveniently also have a way to stop the QEMU driver being locally activated. Next up, event loops. First, we don't want to mandate a particular impl of an event loop. If you get into the argument about QT vs GLib vs libevent and libvirt picks one, then you make it hard for libvirt to integrate with apps using the other. Second, we don't want to assume that 1 connection == 1 file handle. We also don't want to assume that the number of file handles used by a driver stays the same over time. Basically we need to expect that any single driver connection will have zero or more file handles that it is interested in. The DBus library deals with this exact same issue & the solution is very simple. The app using the libvirt registers a callback which the internal driver than then use to (un)register file handles. So in src/internal.h we'd add methods for internal drivers to call to add / remove file handles to/from the event loop: /* * @fd: the file handle on which the event occurred * @event: bitset of one or more of POLLxxx constants from poll.h * @opaque: data associated with 'fd' * * Return 0 to continue monitoring, -1 if an error occurred * and the handle should no longer be monitored */ typedef int (*virEventCallback)(int fd, int events, void *opaque); /* * @fd: the file handle to start monitoring * @events: bitset of POLLxxx contants to monitor * @cb: callback to invoke when an event ocurrs * @opaque: data to pass into callback's opaque parameter */ int virEventAddHandle(int fd, int events, virEventCallback cb, void *opaque); /* * @fd: the file handle to stop monitoring */ int virEventRemoveHandle(int fd); And we'd also add methods for a user of libvirt to register an event loop implementation: typedef int (*virEventAddHandleImpl)(int fd, int events, opaque); typedef int (*virEventRemoveHandleImpl)(int fd); void virEventInitialize(virEventAddHandleImpl add, virEventRemoveHandleImpl remove); If we want to add support for async events into the public API, then the virEventInitialize method could instead be in libvirt.h, and exported in the libvirt.so. Otherwise we could mark it private __virEventInitialize in libvirt.so. That I think should be enough to let us move QEMU into a regular style libvirt driver. NB, what follows now is a quick brain-dump - I'm not suggesting implementing this yet - its really a rough idea of general architecture. We'd definitely want to prototype it in a test app before committing to something like this. There's also many many scenarios to be thought about beyond just watching create/destroy events Thinking about a public API we could have: enum { VIR_CONN_DOMAIN_CREATED, VIR_CONN_DOMAIN_DESTROYED; } virConnectEvent; typedef int (*virConnectNotifyCallback)(virConnectPtr dom, unsigned char uuid[16], int event); virConnectNotify(virConnectPtr conn, virConnectNofifyCallback cb); An application using this would thus be able to do something like /* Assume there's a convenient libvirtglib.so addon providing these for apps */ extern virEventAddHandleImpl virGLibEventAddHandle; extern virEventRemoveHandleImpl virGLibEventRemoveHandle; int domainWatcher(virConnectPtr dom, unsigned char uuid[16], int event) { ... do something ... } int main () { virConnectPtr con; con = virConnectOpen(NULL); /* Setup an event loop via glib */ virEventInitilize(virGLibEventAddHandle, virGLibEventRemoveHandle); virConnectNotify(conn, domainWatcher); 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] Fields in virDomainPtr which appear to be never used
by Richard W.M. Jones 08 May '07

08 May '07

Below is the definition of struct _virDomain from internal.h. I may be missing something big (well, it wouldn't be the first time), but as far as I can see some of these fields are never used, and some are set but can never be read. struct _virDomain { unsigned int magic; /* specific value to check */ OK int uses; /* reference count */ OK virConnectPtr conn; /* pointer back to the connection */ OK char *name; /* the domain external name */ OK char *path; /* the domain internal path */ This field is set in src/xs_internal.c, but nowhere in libvirt does it appear to be read. The only other time it is reference is in hash.c where it is freed if non-NULL. int id; /* the domain ID */ OK int flags; /* extra flags */ Apparently this field could be set to DOMAIN_IS_SHUTDOWN or DOMAIN_IS_DEFINED. However neither of these symbols are used, and moreover this structure field looks like it is never written or read. unsigned char uuid[VIR_UUID_BUFLEN]; /* the domain unique identifier */ OK char *xml; /* the XML description for defined domains */ This field is, as far as I can tell, never set anywhere. However the code in hash.c does check whether it is set and will free it upon destruction of the _virDomain object. }; With this analysis in mind, attached is a patch which removes these three fields (path, flags, xml) and the unused virDomainFlags, with no apparent ill-effects. 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] [PATCH] Fix the value of XEN_V2_OP_GETDOMAININFOLIST
by Saori Fukuta 08 May '07

08 May '07

Hi, The value of "Max memory" shown by using "virsh dominfo" is different from xm command. # virsh dominfo HVM_RH5_sda6 | grep mem Max memory: 300000 kB Used memory: 264064 kB # xm li -l HVM_RH5_sda6 | grep mem (maxmem 450) (memory 292) (shadow_memory 5) So, I changed the definition as follows, (before) #define XEN_V2_OP_GETDOMAININFOLIST 6 (changed) #define XEN_V2_OP_GETDOMAININFOLIST 5 and I could get the value that I want. # ./virsh dominfo HVM_RH5_sda6 | grep mem Max memory: 460800 kB Used memory: 299008 kB # xm li -l HVM_RH5_sda6 | grep mem (maxmem 450) (memory 292) (shadow_memory 5) I think that is not mistake because the XEN_V2_OP_GETDOMAININFOLIST is a system operation, so the definition is not exactly wrong. /usr/include/xen/sysctl.h:#define XEN_SYSCTL_getdomaininfolist 6 Do you know any reason for this? Signed-off-by: Saori Fukuta <fukuta.saori(a)jp.fujitsu.com> Thanks, Saori Fukuta. Index: xen_internal.c =================================================================== RCS file: /data/cvs/libvirt/src/xen_internal.c,v retrieving revision 1.71 diff -u -p -r1.71 xen_internal.c --- xen_internal.c 13 Apr 2007 00:43:57 -0000 1.71 +++ xen_internal.c 26 Apr 2007 11:41:03 -0000 @@ -117,7 +117,7 @@ static regex_t xen_cap_rec; #define XEN_V0_OP_GETDOMAININFOLIST 38 #define XEN_V1_OP_GETDOMAININFOLIST 38 -#define XEN_V2_OP_GETDOMAININFOLIST 6 +#define XEN_V2_OP_GETDOMAININFOLIST 5 struct xen_v0_getdomaininfo { domid_t domain; /* the domain number */

3 7

[Libvir] Request for minimum memory level of dom0 (xen)
by Jan Michael 08 May '07

08 May '07

Hi LibVirt-Mailreaders, Is it possible to provide information about the minimum memory level of domain 0 (xen)? The value is located in the xen deamon config file as "dom0-min-mem". I would like to calculate on the basis of this value if there is enough memory left to create additional domains. Thanks in advance, Jan Michael

2 1

[Libvir] The fist problem to compile libvirt in a Debian etch.
by Marco Sinhoreli 07 May '07

07 May '07

Hello list, I'm writing a how-to about libvirt compilation in Debian Etch. Well, I tried to compile version 0.1.11 in a Debian etch completly newly built from debootstrap. These are the steps that I took: ----- init commands apt-get install make gcc # cd /usr/src && wget http://libvirt.org/sources/libvirt-cvs-snapshot.tar.gz&& tar -xzvf libvirt-cvs-snapshot.tar.gz # cd libvirt-0.1.11 # ./configure checking build system type... i686-pc-linux-gnulibc1 checking host system type... i686-pc-linux-gnulibc1 checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... no checking for mawk... mawk checking whether make sets $(MAKE)... yes checking for gcc... gcc checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. # tail config.log #define PACKAGE "libvirt" #define PACKAGE_BUGREPORT "" #define PACKAGE_NAME "" #define PACKAGE_STRING "" #define PACKAGE_TARNAME "" #define PACKAGE_VERSION "" #define VERSION "0.1.11" configure: exit 77 ----- finish commands I don't know what's the problem. Ideas please... thanks -- Marco Sinhoreli

4 7

Re: [Libvir] The fist problem to compile libvirt in a Debian etch.
by Marco Sinhoreli 05 May '07

05 May '07

Hello list, I changed the libvirt version and now I'm a one step forward ;-) So, I installed these debian packages and I runned the commands above: ------ # apt-get install gcc make g++ autogen gettext autoconf automake libncurses5-dev libxml2 libxml2-dev libreadline5-dev # cd /usr/src # wget http://libvirt.org/sources/libvirt-0.2.2.tar.gz # tar -xzvf libvirt-0.2.2.tar.gz && cd libvirt-0.2.2 # ./configure -with-libxml=/usr # make In this step the make command retur a error: [...] gcc -g -O2 -o .libs/virsh virsh-virsh.o virsh-console.o ./.libs/libvirt.so -L/usr/lib /usr/lib/libxml2.so -lcurses -lreadline -Wl,--rpath -Wl,/usr/local/lib virsh-virsh.o: In function `cmdVcpuinfo': /usr/src/libvirt-0.2.2/src/virsh.c:1230: undefined reference to `__stack_chk_guard' /usr/src/libvirt-0.2.2/src/virsh.c:1294: undefined reference to `__stack_chk_guard' /usr/src/libvirt-0.2.2/src/virsh.c:1294: undefined reference to `__stack_chk_fail' virsh-virsh.o: In function `cmdDominfo': /usr/src/libvirt-0.2.2/src/virsh.c:1153: undefined reference to `__stack_chk_guard' /usr/src/libvirt-0.2.2/src/virsh.c:1211: undefined reference to `__stack_chk_guard' /usr/src/libvirt-0.2.2/src/virsh.c:1211: undefined reference to `__stack_chk_fail' virsh-virsh.o: In function `cmdNetworkUuid': /usr/src/libvirt-0.2.2/src/virsh.c:2227: undefined reference to `__stack_chk_guard' /usr/src/libvirt-0.2.2/src/virsh.c:2244: undefined reference to `__stack_chk_guard' /usr/src/libvirt-0.2.2/src/virsh.c:2244: undefined reference to `__stack_chk_fail' virsh-virsh.o: In function `cmdNetworkDefine': /usr/src/libvirt-0.2.2/src/virsh.c:1854: undefined reference to `__stack_chk_guard' /usr/src/libvirt-0.2.2/src/virsh.c:1890: undefined reference to `__stack_chk_guard' /usr/src/libvirt-0.2.2/src/virsh.c:1890: undefined reference to `__stack_chk_fail' virsh-virsh.o: In function `cmdNetworkCreate': /usr/src/libvirt-0.2.2/src/virsh.c:1798: undefined reference to `__stack_chk_guard' /usr/src/libvirt-0.2.2/src/virsh.c:1834: undefined reference to `__stack_chk_guard' /usr/src/libvirt-0.2.2/src/virsh.c:1834: undefined reference to `__stack_chk_fail' virsh-virsh.o: In function `cmdDomuuid': /usr/src/libvirt-0.2.2/src/virsh.c:1712: undefined reference to `__stack_chk_guard' /usr/src/libvirt-0.2.2/src/virsh.c:1728: undefined reference to `__stack_chk_guard' /usr/src/libvirt-0.2.2/src/virsh.c:1728: undefined reference to `__stack_chk_fail' virsh-virsh.o: In function `cmdNodeinfo': /usr/src/libvirt-0.2.2/src/virsh.c:1542: undefined reference to `__stack_chk_guard' /usr/src/libvirt-0.2.2/src/virsh.c:1562: undefined reference to `__stack_chk_guard' /usr/src/libvirt-0.2.2/src/virsh.c:1562: undefined reference to `__stack_chk_fail' virsh-virsh.o: In function `cmdDefine': /usr/src/libvirt-0.2.2/src/virsh.c:733: undefined reference to `__stack_chk_guard' /usr/src/libvirt-0.2.2/src/virsh.c:769: undefined reference to `__stack_chk_guard' /usr/src/libvirt-0.2.2/src/virsh.c:769: undefined reference to `__stack_chk_fail' virsh-virsh.o: In function `cmdCreate': /usr/src/libvirt-0.2.2/src/virsh.c:678: undefined reference to `__stack_chk_guard' /usr/src/libvirt-0.2.2/src/virsh.c:714: undefined reference to `__stack_chk_guard' /usr/src/libvirt-0.2.2/src/virsh.c:714: undefined reference to `__stack_chk_fail' virsh-virsh.o: In function `vshCmddefHelp': /usr/src/libvirt-0.2.2/src/virsh.c:2563: undefined reference to `__stack_chk_guard' /usr/src/libvirt-0.2.2/src/virsh.c:2609: undefined reference to `__stack_chk_guard' /usr/src/libvirt-0.2.2/src/virsh.c:2609: undefined reference to `__stack_chk_fail' virsh-virsh.o: In function `cmdVcpupin': /usr/src/libvirt-0.2.2/src/virsh.c:1315: undefined reference to `__stack_chk_guard' /usr/src/libvirt-0.2.2/src/virsh.c:1384: undefined reference to `__stack_chk_guard' /usr/src/libvirt-0.2.2/src/virsh.c:1384: undefined reference to `__stack_chk_fail' virsh-console.o: In function `vshRunConsole': /usr/src/libvirt-0.2.2/src/console.c:45: undefined reference to `__stack_chk_guard' /usr/src/libvirt-0.2.2/src/console.c:179: undefined reference to `__stack_chk_guard' /usr/src/libvirt-0.2.2/src/console.c:179: undefined reference to `__stack_chk_fail' ./.libs/libvirt.so: undefined reference to `__stack_chk_fail_local' collect2: ld returned 1 exit status make[2]: ** [virsh] Erro 1 make[2]: Saindo do diretório `/usr/src/libvirt-0.2.2/src' make[1]: ** [all-recursive] Erro 1 make[1]: Saindo do diretório `/usr/src/libvirt-0.2.2' make: ** [all] Erro 2 # ------------------------- I don't know why this error. Ideas? regards, Marco Sinhoreli

2 2

[Libvir] build problems with latest cvs version
by Jan Michael 04 May '07

04 May '07

Hi libvirt-list, I run into the same build problem with version libvirt version 0.2.1, 0.2.2 and the latest cvs-version. In libvirt directory I did the following (for cvs version) ./autogen.sh --disable-shared --disable-QEMU I'd like to disable shared libraries and QEMU support (I have only installed xen 3.0.3 envrionment). The make process breaks while building in [/opt/test/libvirt/qemud], while doing the following: <make output> if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/include/libxml2 -I../ include -I../include -I/usr/include/libxml2 -Wp,-D_FORTIFY_SOURCE=2 - fexceptions -fasynchronous-unwind-tables -Wall -Wmissing-prototypes - Wnested-externs -Wpointer-arith -Wextra -Wshadow -Wcast-align -Wwrite- strings -Waggregate-return -Wstrict-prototypes -Winline -Wredundant- decls -Wno-sign-compare -DLOCAL_STATE_DIR="\"/usr/local/var\"" - DSYSCONF_DIR="\"/usr/local/etc\"" -DQEMUD_PID_FILE="\"/usr/local/var/ run/libvirt_qemud.pid\"" -g -O2 -MT libvirt_qemud-bridge.o -MD -MP - MF ".deps/libvirt_qemud-bridge.Tpo" -c -o libvirt_qemud-bridge.o `test -f 'bridge.c' || echo './'`bridge.c; \ then mv -f ".deps/libvirt_qemud-bridge.Tpo" ".deps/libvirt_qemud- bridge.Po"; else rm -f ".deps/libvirt_qemud-bridge.Tpo"; exit 1; fi bridge.c: In function `brAddBridge': bridge.c:130: error: `SIOCBRADDBR' undeclared (first use in this function) bridge.c:130: error: (Each undeclared identifier is reported only once bridge.c:130: error: for each function it appears in.) bridge.c: In function `brDeleteBridge': bridge.c:148: error: `SIOCBRDELBR' undeclared (first use in this function) bridge.c: In function `brAddInterface': bridge.c:182: error: `SIOCBRADDIF' undeclared (first use in this function) bridge.c: In function `brDeleteInterface': bridge.c:190: error: `SIOCBRDELIF' undeclared (first use in this function) bridge.c: In function `brSetForwardDelay': bridge.c:481: error: `SYSFS_BRIDGE_ATTR' undeclared (first use in this function) bridge.c:481: error: syntax error before string constant bridge.c:481: warning: empty body in an if-statement bridge.c: In function `brGetForwardDelay': bridge.c:503: error: `SYSFS_BRIDGE_ATTR' undeclared (first use in this function) bridge.c:503: error: syntax error before string constant bridge.c:503: warning: empty body in an if-statement bridge.c: In function `brSetEnableSTP': bridge.c:531: error: `SYSFS_BRIDGE_ATTR' undeclared (first use in this function) bridge.c:531: error: syntax error before string constant bridge.c:531: warning: empty body in an if-statement bridge.c: In function `brGetEnableSTP': bridge.c:553: error: `SYSFS_BRIDGE_ATTR' undeclared (first use in this function) bridge.c:553: error: syntax error before string constant bridge.c:553: warning: empty body in an if-statement </make output> I get the same even on the older versions 0.2.2 and 0.2.1. Can you please help me to solve this compilation error? Many thanks in advance, Jan Michael

4 12

[Libvir] PATCH: Remove duplicate graphics for HVM on 3.0.5
by Daniel P. Berrange 03 May '07

03 May '07

In the Xen 3.0.5 series, the HVM graphics config was moved to use the same syntax as Paravirt (ie the pvfb devices). I previously added support for this, but didn't realize that the old syntax was kept as back-compat when doing 'xm list --long' or equiv. So we're ending up with 2 <graphics> elements with the same information. This patch makes us ignore the old style config if running on new XenD. 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: Disable xm_internal.c on newer XenD
by Daniel P. Berrange 02 May '07

02 May '07

The xm_internal.c driver (that processes /etc/xen config files) is only ever intended to be used on XenD <= 3.0.3 There are impls of all the methods in xend_internal.c that take priority on newer XenD, since the xend driver is before it in the stack. The only flaw is that upon failure of one of the xend method libvirt will carry on & invoke the xm_internal driver method. The attached patch addresses this by completely disabling the xm_internal driver on XenD >= 3.0.4 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 3

[Libvir] PATCH: Use --strict-order with dnsmasq
by Daniel P. Berrange 02 May '07

02 May '07

A bug reported by David Lutterkort... The 'man resolv.conf' docs for 'nameserver' say [quote] nameserver Name server IP address Internet address (in dot notation) of a name server that the resolver should query. Up to MAXNS (currently 3, see <resolv.h>) name servers may be listed, one per keyword. If there are multi- ple servers, the resolver library queries them in the order listed. If no nameserver entries are present, the default is to use the name server on the local machine. (The algorithm used is to try a name server, and if the query times out, try the next, until out of name servers, then repeat trying all the name servers until a maximum number of retries are made.) [/quote] While 'man dnsmasq' docs for 'strict-order' say: [quote] -o, --strict-order By default, dnsmasq will send queries to any of the upstream servers it knows about and tries to favour servers to are known to be up. Setting this flag forces dnsmasq to try each query with each server strictly in the order they appear in /etc/resolv.conf [/quote] So by default, the algorithm dnsmasq uses for DNS lookups is a) Different from that use by GLibC b) Wrong Thus I think we should always use --strict-order when running dnsmasq. The attached patch adds this 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 4

[Libvir] [PATCH] Allow network drivers to decline to take a connection
by Richard W.M. Jones 02 May '07

02 May '07

A couple of problems fixed in the attached patch. Firstly the path used to connect to the network driver in non-root mode was wrong. This may have affected you if you tried to use the test:///default driver as non-root. I haven't tested this fully, but in any case the path is obviously wrong and needs to be fixed. Secondly remote introduces its own network driver, and so we now need to allow network drivers to decline to take a connection (currently they either succeed or give an error - meaning in effect that there can only be one network driver). The first part of the attached patch allows this. 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 3

[Libvir] [PATCH] Synchronous daemon restart
by Mark McLoughlin 02 May '07

02 May '07

Hey, See: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=238492 Basically, doing a "service libvirtd restart", you see: libvirt-qemud: Failed to autostart network 'default': cannot create bridge 'virbr0' : File exists and the default network is broken. The problem turns out to be that the initscript doesn't wait before the old daemon has shut down before starting the new one. The fix is simple - if you don't pass a kill level argument to killproc(), then it will block for a few seconds until the daemon has shutdown before killing it with a SIGKILL. Cheers, Mark. Index: qemud/libvirtd.in =================================================================== RCS file: /data/cvs/libvirt/qemud/libvirtd.in,v retrieving revision 1.1 diff -u -p -r1.1 libvirtd.in --- qemud/libvirtd.in 23 Feb 2007 12:50:58 -0000 1.1 +++ qemud/libvirtd.in 2 May 2007 16:47:18 -0000 @@ -34,7 +34,7 @@ start() { stop() { echo -n $"Stopping $SERVICE daemon: " - killproc $PROCESS -TERM + killproc $PROCESS RETVAL=$? echo if [ $RETVAL -eq 0 ]; then

2 3

[Libvir] [PATCH] Don't throw away errors in virConnectOpen (at least not so often)
by Richard W.M. Jones 02 May '07

02 May '07

Error messages, I like them. I don't like them to be thrown away. A nice feature of virterror is that it'll throw away errors under the following conditions: (1) You are in virConnectOpen, and (2) You pass a non-NULL virConnectPtr to __virRaiseError. libvirt has a lot of errors which meet those conditions - the attached patch fixes the ones I could find. It also fixes qemuOpenConnection so that it doesn't try to open a Unix socket with random stack data. It also adds error messages in some useful places where previously there was an error, but no message. 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)

3 3

[Libvir] PATCH: Support <on_reboot>poweroff</on_reboot> in QEMU/KVM
by Daniel P. Berrange 02 May '07

02 May '07

Currently in the QEMU driver we don't support any of the customizable shutdown operation behaviour elements in the XML. ie <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> This was principally because we don't particularly have a good way to actually implement some of them. Well, QEMU 0.9.0 added a -no-reboot flag which could be used to force a 'reboot' inside the guest to behaviour like a shutdown. So we can now support at least the <on_reboot> element with 'destroy' or 'restart' behaviours. This turns out to be critical for provisioning guests, because the initial install uses a different VM configs, from later runtime, eg boot from ISO, vs boot from Disk. The attached patch adds support for accepting <on_reboot> when defining new domain configs. When dumping XML we will also add <on_poweroff> and <on_crash> elements to at least indicate what our behaviour is, though the user can't customize them. In doing this patch I had to change the way we read data from QEMU. We were over the 4096 buffer size, and also in some cases we were getting a short read which meant we lost the end of the help message. We now have a buffer of 8k (max QEMU help is 5k currently), and read in a loop until EOF or 8k is hit. 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] Allow virDomainDefine to overwrite existing inactive domains for xen 3.0.3 userspace installations
by Hugh Brock 02 May '07

02 May '07

virDomainDefineXML should overwrite an existing inactive domain config if it finds one; it does this successfully for later (post 3.0.3) xen versions. However on xen 3.0.3 overwriting an existing config would fail with a name conflict. This patch allows the overwrite, removing the prior config from the config hashes. If someone more familiar than I with libvirt error handling and style could look at this and tell me if I've done something horribly wrong, I'd appreciate it. Signed-off-by: Hugh Brock <hbrock(a)redhat.com> -- Red Hat Virtualization Group http://redhat.com/virtualization Hugh Brock | virt-manager http://virt-manager.org hbrock(a)redhat.com | virtualization library http://libvirt.org

3 2

[Libvir] Remote patch, 2007-05-01
by Richard W.M. Jones 02 May '07

02 May '07

This is a patch against CVS -- in other words, it includes the two previous patches I sent to this list today. Compared to the previous patch, it's just bug fixes and testing. Sorry, these patches are getting rather huge. Unfortunately I can't see any sensible way to split it up. For the most part you either have remote support or you don't. 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] RFC: Behaviour of virConnectSave, Restore and CoreDump in the remote case
by Richard W.M. Jones 02 May '07

02 May '07

virDomainSave (for example) is currently defined like this: /** * virDomainSave: * @domain: a domain object * @to: path for the output file * * This method will suspend a domain and save its memory contents to * a file on disk. After the call, if successful, the domain is not * listed as running anymore (this may be a problem). * Use virDomainRestore() to restore a domain after saving. * * Returns 0 in case of success and -1 in case of failure. */ In the remote case there are, I think, three possible things that this call could do: (A) Copy the image over the network connection to save it locally This is possibly the most "authentic" option. Callers using remote can specify a local path and the image file will appear at that path, locally, making the remote case reasonably transparent. However image files are usually pretty large, and copying them over a network connection could be slow. In particular the network connection may be over loopback -- eg. in the case where we are allowing ordinary users to connect to a locally running libvirtd with elevated priviledges. (It's quite hard in general to determine if remote is really connected to a different machine, eg. think about the case where we are using ssh tunnels). In some ways this is the most secure option. The image or core dump is written by the user process, so there is no way to get a daemon with elevated privs to write over a file in /etc for example. (B) Save it remotely Remote isn't transparent. We save it remotely. We could consider adding a virDomainSaveLocal API call for the case when we really want to save it locally. (C) Do nothing / present an error Recognise that remote cannot deal with this at the moment, and don't implement this call. Perhaps come back to it later in the context of remote storage management. Opinions? 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] [PATCH] increase storage domains of a definition file
by S.Sakamoto 02 May '07

02 May '07

Hi, When I install by virt-intall with long command (e.g."# /usr/sbin/virt-install --name testvm --ram 350 --vcpus 2 --file /root/test.img --file-size 1 --file /root/tmp02.img -- file-size 1 --file /root/tmp03.img --file-size 1 --file /root/tmp04.img --file-size 1 --file /root/tmp05.img --file-size 1 --file /root/tmp06.img --file-size 1 --file /root/tmp07.img --file-size 1 --file /root/tmp08.img --file-size 1 --file /root/tmp09.img --file-size 1 --file /root/tmp10.img --file-size 1 --file /root/tmp11.img --file-size 1 --file /root/tmp12.img --file-size 1 --file /root/tmp13.img --file-size 1 --file /root/tmp14.img --file-size 1 --file /root/tmp15.img --file-size 1 --file /root/tmp16.img --file-size 1 --vnc --paravirt --location ftp://xx.xx.xx.xx/rhel5ga_x86 --noautoconsole -- debug"), put out "abort". Because a definition file is long, it overflows from buffer. So, this patch increase buffer size. Signed-off-by: Shigeki Sakamoto <fj0588di(a)aa.jp.fujitsu.com> Thanks, Shigeki Sakamoto. Index: src/internal.h =================================================================== RCS file: /data/cvs/libvirt/src/internal.h,v retrieving revision 1.37 diff -u -p -r1.37 internal.h --- src/internal.h 4 Apr 2007 14:19:49 -0000 1.37 +++ src/internal.h 19 Apr 2007 11:01:12 -0000 @@ -106,6 +106,11 @@ extern "C" { #define VIR_CONNECT_RO 1 /** + * buffer size for definition file + */ +#define VIR_XML_STRING_BUFLEN (1024 + PATH_MAX * 16 + FILENAME_MAX * 16) + +/** * _virConnect: * * Internal structure associated to a connection Index: src/xend_internal.c =================================================================== RCS file: /data/cvs/libvirt/src/xend_internal.c,v retrieving revision 1.109 diff -u -p -r1.109 xend_internal.c --- src/xend_internal.c 13 Apr 2007 14:08:38 -0000 1.109 +++ src/xend_internal.c 19 Apr 2007 11:01:16 -0000 @@ -587,7 +587,7 @@ static int xend_op_ext2(virConnectPtr xend, const char *path, char *error, size_t n_error, const char *key, va_list ap) { - char ops[1024]; + char ops[VIR_XML_STRING_BUFLEN]; const char *k = key, *v; int offset = 0; Index: src/xml.c =================================================================== RCS file: /data/cvs/libvirt/src/xml.c,v retrieving revision 1.72 diff -u -p -r1.72 xml.c --- src/xml.c 13 Apr 2007 00:43:57 -0000 1.72 +++ src/xml.c 19 Apr 2007 11:01:20 -0000 @@ -1165,7 +1165,7 @@ virDomainParseXMLDesc(virConnectPtr conn { xmlDocPtr xml = NULL; xmlNodePtr node; - char *ret = NULL, *nam = NULL; + char *nam = NULL; virBuffer buf; xmlChar *prop; xmlParserCtxtPtr pctxt; @@ -1182,10 +1182,9 @@ virDomainParseXMLDesc(virConnectPtr conn if (name != NULL) *name = NULL; - ret = malloc(1000); - if (ret == NULL) + buf.content = malloc(1000); + if (buf.content == NULL) return (NULL); - buf.content = ret; buf.size = 1000; buf.use = 0; @@ -1376,7 +1375,7 @@ virDomainParseXMLDesc(virConnectPtr conn else free(nam); - return (ret); + return (buf.content); error: if (nam != NULL) @@ -1389,8 +1388,8 @@ virDomainParseXMLDesc(virConnectPtr conn xmlFreeDoc(xml); if (pctxt != NULL) xmlFreeParserCtxt(pctxt); - if (ret != NULL) - free(ret); + if (buf.content != NULL) + free(buf.content); return (NULL); }

5 9

[Libvir] Proposed remote protocol (XDR source file qemud/remote_protocol.x)
by Richard W.M. Jones 01 May '07

01 May '07

Attached are the args (*_args) and return structures (*_ret) for all the calls covered by the remote protocol, that is to say everything except Save, Restore and CoreDump (see previous email). The only problem area are the upper limits imposed on the lengths of various strings and arrays. The upper limits seem to be required for safely decoding messages from untrusted sources. Some of them however would impose limits on such things as the number of CPUs supported, and perhaps those limits are too low (or too high)? I don't really have any experience of the sort of huge machines that people might be running libvirt on. 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) /* -*- c -*- * remote_protocol.x: private protocol for communicating between * remote_internal driver and libvirtd. This protocol is * internal and may change at any time. * * Copyright (C) 2006-2007 Red Hat, Inc. * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public * License as published by the Free Software Foundation; either * version 2.1 of the License, or (at your option) any later version. * * This library is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU * Lesser General Public License for more details. * * You should have received a copy of the GNU Lesser General Public * License along with this library; if not, write to the Free Software * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA * * Author: Richard Jones <rjones(a)redhat.com> */ /* Notes: * * (1) The protocol is internal and may change at any time, without * notice. Do not use it. Instead link to libvirt and use the remote * driver. * * (2) See bottom of this file for a description of the home-brew RPC. * * (3) Authentication/encryption is done outside this protocol. * * (4) For namespace reasons, all exported names begin 'remote_' or * 'REMOTE_'. This makes names quite long. */ %#include "libvirt/libvirt.h" /*----- Data types. -----*/ /* Maximum total message size (serialised). */ const REMOTE_MESSAGE_MAX = 262144; /* Length of long, but not unbounded, strings. * This is an arbitrary limit designed to stop the decoder from trying * to allocate unbounded amounts of memory when fed with a bad message. */ const REMOTE_STRING_MAX = 65536; /* A long string, which may NOT be NULL. */ typedef string remote_nonnull_string<REMOTE_STRING_MAX>; /* A long string, which may be NULL. */ typedef remote_nonnull_string *remote_string; /* This just places an upper limit on the length of lists of * domain IDs which may be sent via the protocol. */ const REMOTE_DOMAIN_ID_LIST_MAX = 4096; /* Upper limit on lists of domain names. */ const REMOTE_DOMAIN_NAME_LIST_MAX = 256; /* Upper limit on cpumap (bytes) passed to virDomainPinVcpu. */ const REMOTE_CPUMAP_MAX = 256; /* Upper limit on number of info fields returned by virDomainGetVcpus. */ const REMOTE_VCPUINFO_MAX = 2048; /* Upper limit on cpumaps (bytes) passed to virDomainGetVcpus. */ const REMOTE_CPUMAPS_MAX = 16384; /* Upper limit on lists of network names. */ const REMOTE_NETWORK_NAME_LIST_MAX = 256; /* Domains and networks are represented on the wire by (name, UUID). */ typedef opaque remote_uuid[VIR_UUID_BUFLEN]; struct remote_name { remote_nonnull_string name; remote_uuid uuid; }; /* A domain or network which may not be NULL. */ typedef struct remote_name remote_nonnull_domain; typedef struct remote_name remote_nonnull_network; /* A domain or network which may be NULL. */ typedef remote_nonnull_domain *remote_domain; typedef remote_nonnull_network *remote_network; /* Error message. See <virterror.h> for explanation of fields. */ /* NB. Fields "code", "domain" and "level" are really enums. The * numeric value should remain compatible between libvirt and * libvirtd. This means, no changing or reordering the enums as * defined in <virterror.h> (but we don't do that anyway, for separate * ABI reasons). */ struct remote_error { int code; int domain; remote_string message; int level; remote_domain dom; remote_string str1; remote_string str2; remote_string str3; int int1; int int2; remote_network net; }; /* Wire encoding of virVcpuInfo. */ struct remote_vcpu_info { unsigned int number; int state; unsigned hyper cpu_time; int cpu; }; /*----- Calls. -----*/ /* For each call we may have a 'remote_CALL_args' and 'remote_CALL_ret' * type. These are omitted when they are NULL. The virConnectPtr * is not passed at all (it is inferred on the remote server from the * connection). Errors are returned implicitly in the RPC protocol. */ struct remote_open_args { /* NB. "name" might be NULL although in practice you can't * yet do that using the remote_internal driver. */ remote_string name; int flags; }; struct remote_get_type_ret { remote_nonnull_string type; }; struct remote_get_version_ret { hyper hv_ver; }; struct remote_get_max_vcpus_args { /* The only backend which supports this call is Xen HV, and * there the type is ignored so it could be NULL. */ remote_string type; }; struct remote_get_max_vcpus_ret { int max_vcpus; }; struct remote_node_get_info_ret { string model<32>; hyper memory; int cpus; int mhz; int nodes; int sockets; int cores; int threads; }; struct remote_get_capabilities_ret { remote_nonnull_string capabilities; }; struct remote_list_domains_args { int maxids; }; struct remote_list_domains_ret { int ids<REMOTE_DOMAIN_ID_LIST_MAX>; }; struct remote_num_of_domains_ret { int num; }; struct remote_domain_create_linux_args { remote_nonnull_string xml_desc; int flags; }; struct remote_domain_create_linux_ret { remote_nonnull_domain dom; }; struct remote_domain_lookup_by_id_args { int id; }; struct remote_domain_lookup_by_id_ret { /* XXX "Not found" semantic is ill-defined. */ remote_nonnull_domain dom; }; struct remote_domain_lookup_by_uuid_args { remote_uuid uuid; }; struct remote_domain_lookup_by_uuid_ret { /* XXX "Not found" semantic is ill-defined. */ remote_nonnull_domain dom; }; struct remote_domain_lookup_by_name_args { remote_nonnull_string name; }; struct remote_domain_lookup_by_name_ret { /* XXX "Not found" semantic is ill-defined. */ remote_nonnull_domain dom; }; struct remote_domain_suspend_args { remote_nonnull_domain dom; }; struct remote_domain_resume_args { remote_nonnull_domain dom; }; struct remote_domain_shutdown_args { remote_nonnull_domain dom; }; struct remote_domain_reboot_args { remote_nonnull_domain dom; int flags; }; struct remote_domain_destroy_args { remote_nonnull_domain dom; }; struct remote_domain_get_os_type_args { remote_nonnull_domain dom; }; struct remote_domain_get_os_type_ret { remote_nonnull_string type; }; struct remote_domain_get_max_memory_args { remote_nonnull_domain dom; }; struct remote_domain_get_max_memory_ret { unsigned hyper memory; }; struct remote_domain_set_max_memory_args { remote_nonnull_domain dom; unsigned hyper memory; }; struct remote_domain_set_memory_args { remote_nonnull_domain dom; unsigned hyper memory; }; struct remote_domain_get_info_args { remote_nonnull_domain dom; }; struct remote_domain_get_info_ret { unsigned char state; unsigned hyper max_mem; unsigned hyper memory; unsigned short nr_virt_cpu; /* XXX cpu_time is declared as unsigned long long */ unsigned hyper cpu_time; }; /* XXX Save, Restore, CoreDump not yet implemented because we * don't know where we will write the images. */ struct remote_domain_dump_xml_args { remote_nonnull_domain dom; int flags; }; struct remote_domain_dump_xml_ret { remote_nonnull_string xml; }; struct remote_domain_list_defined_domains_args { int maxnames; }; struct remote_domain_list_defined_domains_ret { remote_nonnull_string names<REMOTE_DOMAIN_NAME_LIST_MAX>; }; struct remote_domain_num_of_defined_domains_ret { int num; }; struct remote_domain_create_args { remote_nonnull_domain dom; }; struct remote_domain_define_xml_args { remote_nonnull_string xml; }; struct remote_domain_define_xml_ret { remote_nonnull_domain dom; }; struct remote_domain_undefine_args { remote_nonnull_domain dom; }; struct remote_domain_set_vcpus_args { int nvcpus; }; struct remote_domain_pin_vcpu_args { int vcpu; opaque cpumap<REMOTE_CPUMAP_MAX>; }; struct remote_domain_get_vcpus_args { remote_nonnull_domain dom; int maxinfo; int maplen; }; struct remote_domain_get_vcpus_ret { remote_vcpu_info info<REMOTE_VCPUINFO_MAX>; opaque cpumaps<REMOTE_CPUMAPS_MAX>; }; struct remote_domain_get_max_vcpus_args { remote_nonnull_domain dom; }; struct remote_domain_get_max_vcpus_ret { int num; }; struct remote_domain_attach_device_args { remote_nonnull_domain dom; remote_nonnull_string xml; }; struct remote_domain_detach_device_args { remote_nonnull_domain dom; remote_nonnull_string xml; }; struct remote_domain_get_autostart_args { remote_nonnull_domain dom; }; struct remote_domain_get_autostart_ret { int autostart; }; struct remote_domain_set_autostart_args { remote_nonnull_domain dom; int autostart; }; /* Network calls: */ struct remote_num_of_networks_ret { int num; }; struct remote_list_networks_args { int maxnames; }; struct remote_list_networks_ret { remote_nonnull_string names<REMOTE_NETWORK_NAME_LIST_MAX>; }; struct remote_num_of_defined_networks_ret { int num; }; struct remote_list_defined_networks_args { int maxnames; }; struct remote_list_defined_networks_ret { remote_nonnull_string names<REMOTE_NETWORK_NAME_LIST_MAX>; }; struct remote_network_lookup_by_uuid_args { remote_uuid uuid; }; struct remote_network_lookup_by_uuid_ret { /* XXX "Not found" semantic is ill-defined. */ remote_nonnull_network net; }; struct remote_network_lookup_by_name_args { remote_nonnull_string name; }; struct remote_network_lookup_by_name_ret { /* XXX "Not found" semantic is ill-defined. */ remote_nonnull_network net; }; struct remote_network_create_xml_args { remote_nonnull_string xml; }; struct remote_network_create_xml_ret { remote_nonnull_network net; }; struct remote_network_define_xml_args { remote_nonnull_string xml; }; struct remote_network_define_xml_ret { remote_nonnull_network net; }; struct remote_network_undefine_args { remote_nonnull_network net; }; struct remote_network_create_args { remote_nonnull_network net; }; struct remote_network_destroy_args { remote_nonnull_network net; }; struct remote_network_dump_xml_args { remote_nonnull_network net; int flags; }; struct remote_network_dump_xml_ret { remote_nonnull_string xml; }; struct remote_network_get_bridge_name_args { remote_nonnull_network net; }; struct remote_network_get_bridge_name_ret { remote_nonnull_string name; }; struct remote_network_get_autostart_args { remote_nonnull_network net; }; struct remote_network_get_autostart_ret { int autostart; }; struct remote_network_set_autostart_args { remote_nonnull_network net; int autostart; }; /*----- Protocol. -----*/ /* Define the program number, protocol version and procedure numbers here. */ const REMOTE_PROGRAM = 0x20008086; const REMOTE_PROTOCOL_VERSION = 1; enum remote_procedure { REMOTE_PROC_OPEN = 1, REMOTE_PROC_CLOSE = 2, REMOTE_PROC_GET_CAPABILITIES = 3 }; /* Custom RPC structure. */ /* Each message consists of: * int length Number of bytes in message _including_ length. * remote_message_header Header. * then either: args Arguments (for REMOTE_CALL). * or: ret Return (for REMOTE_REPLY, status = REMOTE_OK) * or: remote_error Error (for REMOTE_REPLY, status = REMOTE_ERROR) * * The first two words (length, program number) are meant to be compatible * with the qemud protocol (qemud/protocol.x), although the rest of the * messages are completely different. */ enum remote_message_direction { REMOTE_CALL = 0, /* client -> server */ REMOTE_REPLY = 1, /* server -> client */ REMOTE_MESSAGE = 2 /* server -> client, asynchronous [NYI] */ }; enum remote_message_status { /* Status is always REMOTE_OK for calls. * For replies, indicates no error. */ REMOTE_OK = 0, /* For replies, indicates that an error happened, and a struct * remote_error follows. */ REMOTE_ERROR = 1 }; struct remote_message_header { unsigned prog; /* REMOTE_PROGRAM */ unsigned vers; /* REMOTE_PROTOCOL_VERSION */ remote_procedure proc; /* REMOTE_PROC_x */ remote_message_direction direction; unsigned serial; /* Serial number of message. */ remote_message_status status; }; /* * vim: set tabstop=4: * vim: set shiftwidth=4: * vim: set expandtab: */ /* * Local variables: * indent-tabs-mode: nil * c-indent-level: 4 * c-basic-offset: 4 * tab-width: 4 * End: */

2 4

[Libvir] [PATCH] Remove VIR_DRV_OPEN_QUIET
by Richard W.M. Jones 30 Apr '07

30 Apr '07

VIR_DRV_OPEN_QUIET causes important diagnostic error messages to be thrown away. This patch removes this. 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] [PATCH] Xen proxy - adds getCapabilities call
by Richard W.M. Jones 30 Apr '07

30 Apr '07

Seems to me that it should be safe to allow non-root callers to use the getCapabilities call over the Xen proxy. This patch adds that feature. 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] [PATCH] Fix xen-unified to work in non-root case
by Richard W.M. Jones 30 Apr '07

30 Apr '07

Xen-unified introduced a stupid bug, down to me, when running in the non-root case. It didn't keep track of which drivers successfully opened, so will try and perform operations on drivers which didn't open. I suggest that if people approve of the attached patch, then it is applied with some urgency. 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] Difference between API functions virConnectNumOfDefinedDomains and virConnectNumOfDomains
by Jan Michael 30 Apr '07

30 Apr '07

Hello libvirt fellows, I have some problems to distinguish between those function calls in libvirt API: > virConnectNumOfDefinedDomains > virConnectNumOfDomains The API description states on both function that they will return me the number of active domain. Am I right if I assume that the first function virConnectNumOfDefinedDomains returns me all defined, but necessarily not running domains, and the second one only running and therefore active domains? Can you please help me and clarify this? Didn't had the chance to test this so far. But I will do so asap. Maybe the API documentation has to be updated in this point. Cheers, Jan

3 3

[Libvir] [PATCH] If xenHypervisorInit fails, produce an error message
by Richard W.M. Jones 27 Apr '07

27 Apr '07

.. and if opening the Xen HV file under /proc fails, show us the errno. 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] Remote patch, 2007-04-27
by Richard W.M. Jones 27 Apr '07

27 Apr '07

This (re-)adds support for TLS and TCP sockets, the configuration file, certificate checking, clients IP address whitelists. 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] Relax NG for network XML
by David Lutterkort 27 Apr '07

27 Apr '07

Hi, I wrote up a basic Relax NG schema for the network XML. It would be nice if those who know these things could look over/expand on the comments on what the various elements do. David

1 0

[Libvir] plans to support vde_switch ?
by adrian.lambeck＠basicsedv.de 27 Apr '07

27 Apr '07

Hello everybody, I am working on a project where I found vde_switch (http://vde.sourceforge.net/) very useful. It is based on uml_switch from the UML project. Are there any plans to support it in libvirt? Thanks. Adrian

3 2

[Libvir] about domctl
by Atsushi SAKAI 27 Apr '07

27 Apr '07

Hi, Dan I have a question about domctl(Xen hypervisor call). It seems not working on Fedora7(i386). But sysctl works fine. for example "virsh setmem" does not set memory. "virsh vcpuinfo " shows following message on dom0 (strange) VCPU: 0 CPU: 0 State: blocked CPU time: 0.0s CPU Affinity: - Would you investigate this issue? I look around the code but it should be works. Thanks Atsushi SAKAI

2 3

[Libvir] [FYI] Holidays of Japan
by Atsushi SAKAI 26 Apr '07

26 Apr '07

Next week Japan has many national holidays.(Apr 29, May 3, 4, 5) http://en.wikipedia.org/wiki/Holidays_of_Japan Someone appeared on May 1 and 2 Thanks Atsushi SAKAI

2 1

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

26 Apr '07

Been on holiday last week, and then got massively sidetracked with query strings in libxml2, so there's not been much progress. Nevertheless, here is the current remote patch. It still needs GnuTLS support to be copied over from the old version, so currently it only listens on Unix sockets. 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] [PATCH][RFC] Adding Cloning Feature
by Kazuki Mizushima 25 Apr '07

25 Apr '07

Hi all, I've been planing to adding cloning feature. Then, I tried to make the patch in the following way. 1)Get the XML used virDomainGetXMLDesc 2)Delete <uuid>, <mac> node element This intened to automatically generated. 3)Changing <name>, <source dev> string node element 4)Fork "dd" process 5)Define XML used virDomainDefineXML This feature is just a first revision, because I make this patch within current libvirt API limitation. Also Remote Cloining is Limited. But if we can libvirtd for feature, it will be enhance remote cloning based on this pach (as http://libvirt.org/remote.html#Remote_libvirtd_configuration) Finally, to have to communicate with the demon remotely as libvirt library, actually I want to put down to new libvirt API (e.g. virDomainClone). Could you hear your comments about this ? Attached patch shows below. --------------------------------------------- # ./virsh --help clone NAME clone - clone a domain SYNOPSIS virsh clone <domain> <devices,...> DESCRIPTION Clone a domain. OPTIONS <domain> shut off state domain name <devices> destination devices (comma separated) # ./virsh clone PV_RH5 /dev/sdb2 Cloning from /dev/sda5 to /dev/sdb2 ..... # ./virsh list --all Id Name State ---------------------------------- 0 Domain-0 running - PV_RH5 shut off - PV_RH5_CLONE shut off #./virsh start PV_RH5_CLONE Domain PV_RH5_CLONE started --------------------------------------------- Thanks, Kazuki Mizushima

4 9

Re: [Libvir] [PATCH][RFC] Adding Cloning Feature
by Kazuki Mizushima 25 Apr '07

25 Apr '07

Hi Rich, > I think cloning is a great feature. From when I used to sysadmin a Xen > server, I used cloning as the main technique to create new servers - ie. > take an existing machine which is similar to the new one which I want, > and just clone it. Thank you for your comments and agreement. > There is no problem with interaction with the remote patch. Nor do you > have to worry about the remote stuff when implementing this (the "dd" > will fork on the remote libvirtd automagically). O.K. I understood it. I warry about remote support for libvirt architecture always. > So the idea is that you can only clone an inactive domain? This first revision, only inactive domain. But next step, I think snapshot command will be able to used instead of "dd". Thanks, Kazuki Mizushima

2 1

[Libvir] Capabilities XML format
by Mark McLoughlin 23 Apr '07

23 Apr '07

Hey, Just a few brief comments after using it: - <os_type>xen<os_type> is equivalent to <os><type>linux</type></os>, which is pretty confusing. Sounds to me like we should deprecate the latter and move to "xen" everywhere for this. - We have <host><arch>x86_64</arch></host> and <guest><arch name="x86_64"/></guest>. I can see why we did that, but it seems odd to me to have different syntaxes for <arch> depending on its context. - I'm not sure how interesting the stuff in <guest><arch> is ... how were we envisaging these bits being used? - It's a pain to have to parse XML to discover whether e.g. you can run a 64 bit guest. I'd much prefer to see the kind of API I'm using here: http://www.gnome.org/~markmc/code/test-caps.py e.g. caps = cnx.getCapabilities() supports_x86_64 = False for guest in caps.guests: if guest.arch == "x86_64": supports_x86_64 = True Cheers, Mark.

2 2

[Libvir] [RFC] Life-cycle Management of the domain
by Saori Fukuta 23 Apr '07

23 Apr '07

Hi all, I've been thinking about a way to change the hardware allocation on the Life-cycle. And I have some idea. Can I hear your comments about this? 1. Necessity of function These are conceivable cases of changing hardware allocation. CASE A: Dynamic change change the allocation dynamically -> change the hardware allocation for now, and next time, start by the allocation before it changes. (example of use) At night, change the hardware allocation. Next morning rebooting, return it. CASE B: Static change change the allocation statically -> do not change the hardware allocation for now, but set the allocation for starting next. (example of use) Next time, want to start by the value that set before. CASE C: Permanent change change the allocation permanently -> change the hardware allocation, and start next time with the same setting. (example of use) want to start by same value permanently. The current situation of virsh command with Xen. CASE A / CASE B / CASE C virsh setmem x x o virsh setmaxmem x x o virsh setvcpus o x x virsh vcpupin o x x And I find that the value on Xenstore is used for starting the domain next time. 2. Change of command We need to add 3 options to the virsh command of changing allocation for CASE A, B, and C. So I propose the following options. option name --dynamic ... dynamic change option (default) for CASE A --static ... static change option for CASE B --perm ... permanent change option for CASE C If no option is specified, the Default option("--dynamic") will be chosen. (example) Example of changing the memory allocation 256MB to 512MB. # virsh dominfo Domain-A | grep "Used memory" Used memory: 256000 kB CASE A: Dynamic change # virsh setmem Domain-A 512000 or # virsh setmem Domain-A 512000 --dynamic # virsh dominfo Domain-A | grep "Used memory" Used memory: 512000 kB CASE B: Static change # virsh setmem Domain-A 512000 --static # virsh dominfo Domain-A | grep "Used memory" Used memory: 256000 kB CASE C: Permanent change # virsh setmem Domain-A 512000 --perm # virsh dominfo Domain-A | grep "Used memory" Used memory: 512000 kB 3. Summary of the ways Xen does not provide these cases. So I propose that we start the domain by a file for libvirt. 3.1 When starting the domain first time, copy a file from config.sxp(/etc/xen config file) to virt.sxp(libvirt). (image) +--- Xend ---+ +-- libvirt --+ +--------+ l config.sxp -------> virt.sxp l +--------+ lDomain-Al +------------+ copy +-------------+ lDomain-Al lmem=256 l lmem=256 l +--------+ ----------------------------------> +--------+ "virsh start Domain-A" 3.2 When starting the domain, if they have virt.sxp(libvirt) define that file. (image) Step.1 value of the domain before start. +--- Xend --------------------+ l +-Xenstore-+ +-config.sxp-+ l before l l mem=256 l l mem=256 l l +--------+ l +----------+ +------------+ l lDomain-Al +-----------------------------+ lmem=256 l +--------+ ---------------------------------> continue Step.2 Step.2 define the value of virt.sxp. +--- Xend ---------------------+ l +-Xenstore-+ +-config.sxp-+ l +----> mem=512 l -> mem=512 l l define l l +----------+ +------------+ l l +------------------------------+ l +--- l --------+ l +- l --------+ before l l mem=512 l l +--------+ l +-virt.sxp-+ l lDomain-Al +--- libvirt --+ lmem=256 l +--------+ ---------------------------------> continue Step.3 Step.3 start the domain and copy a file from config.sxp to virt.sxp. +--- Xend ---------------------+ l +-Xenstore-+ +-config.sxp-+ l l l mem=512 l l mem=512 l l l +--- l ----+ +----- l ----+ l +----- l ------------- l ------+ l l +--- libvirt --+ l l copy l +-virt.sxp-+ l l +-------------> mem=256 l l before l l +----------+ l +--------+ l start +--------+ +--------------+ lDomain-Al +------------>lDomain-Al lmem=256 l lmem=512 l +--------+ -------------------> +--------+ "virsh start Domain-A" 3.3 When changing the allocation statically or permanently, write the change into virt.sxp. (When changing the allocation dynamically, do nothing) CASE A: Dynamic change (image) +--- Xend --------------------+ ll next start l +-Xenstore-+ +-config.sxp-+ l ll l l mem=512 l l mem=512 l l ll l +----------+ +------------+ l ll +-----------------------------+ ll +--- libvirt --+ ll l +-virt.sxp-+ l ll before l l mem=256 l l after ll +--------+ l +----------+ l +--------+ ll +--------+ lDomain-Al +--------------+ lDomain-Al ll lDomain-Al lmem=256 l lmem=512 l ll lmem=256 l +--------+ -------------------------------> +--------+ ll +--------+ "virsh setmem Domain-A 512000" ll (state transition matrix) +-------------------------------------------------------------+ operational procedure Xend libvirt Xenstore config.sxp virt.sxp +-------------------------------------------------------------+ 1.start the domain mem=X, mem=X --->mem=X(create file) 2.change the allocation mem=Y, mem=Y mem=X(no change) mem X to Y dynamically 3.stop the domain mem=Y, mem=Y mem=X 4.start the domain <------- <-----------define value mem=X, mem=X --->mem=X(create file) 5.delete the domain del del delete file +-------------------------------------------------------------+ CASE B: Static change (image) +--- Xend --------------------+ ll next start l +-Xenstore-+ +-config.sxp-+ l ll l l mem=256 l l mem=256 l l ll l +----------+ +------------+ l ll +-----------------------------+ ll +--- libvirt --+ ll l +-virt.sxp-+ l ll before l l mem=512 l l after ll +--------+ l +----------+ l +--------+ ll +--------+ lDomain-Al +--------------+ lDomain-Al ll lDomain-Al lmem=256 l lmem=256 l ll lmem=512 l +--------+ -------------------------------> +--------+ ll +--------+ "virsh setmem Domain-A 512000 --static" ll (state transition matrix) +-------------------------------------------------------------+ operational procedure Xend libvirt Xenstore config.sxp virt.sxp +-------------------------------------------------------------+ 1.start the domain mem=X, mem=X --->mem=X(create file) 2.change the allocation mem=X, mem=Y mem=Y(change to Y) mem X to Y statically 3.stop the domain mem=X, mem=X mem=Y 4.start the domain <------- <-----------define value mem=Y, mem=Y --->mem=Y(create file) 5.delete the domain del del delete file +-------------------------------------------------------------+ CASE C: Permanent change (image) +--- Xend --------------------+ ll next start l +-Xenstore-+ +-config.sxp-+ l ll l l mem=512 l l mem=512 l l ll l +----------+ +------------+ l ll +-----------------------------+ ll +--- libvirt --+ ll l +-virt.sxp-+ l ll before l l mem=512 l l after ll +--------+ l +----------+ l +--------+ ll +--------+ lDomain-Al +--------------+ lDomain-Al ll lDomain-Al lmem=256 l lmem=512 l ll lmem=512 l +--------+ -------------------------------> +--------+ ll +--------+ "virsh setmem Domain-A 512000 --perm" ll (state transition matrix) +-------------------------------------------------------------+ operational procedure Xend libvirt Xenstore config.sxp virt.sxp +-------------------------------------------------------------+ 1.start the domain mem=X, mem=X --->mem=X(create file) 2.change the allocation mem=Y, mem=Y mem=Y(change to Y) mem X to Y permanently 3.stop the domain mem=Y, mem=Y mem=Y 4.start the domain <------- <-----------define value mem=Y, mem=Y --->mem=Y(create file) 5.delete the domain del del delete file +-------------------------------------------------------------+ Thanks, Saori Fukuta

3 8

[Libvir] Remote & the problem with qemu deadlock
by Richard W.M. Jones 19 Apr '07

19 Apr '07

As I wrote here: https://www.redhat.com/archives/libvir-list/2007-April/msg00114.html remote access to qemu:/// URLs currently deadlocks. A bit of explanation follows as to why this happens in the current architecture of the remote patch. If you apply the remote patch right now, you'll get a modified libvirt_qemud server which can handle both qemu and remote requests over the same socket. (Basically both qemu_internal.c and remote_internal.c connect to the same Unix domain socket, then depending on the "program number" encoded within the RPC messages, they get dispatched accordingly inside libvirt_qemud). The server is written to handle multiple connections at once using non-blocking poll[1], but once the server has assembled a whole incoming message, it then blocks while dealing with that message. The problem occurs in the qemu case when the remote server issues a call into qemu_internal (now linked into the server), and qemu_internal then tries to connect out to the qemu daemon. Unfortunately the qemu daemon /is/ the remote server, which is blocked handling the current call. Thus it is unable to accept the new connection (from itself) and completely deadlocks. One solution suggested was to have qemu_internal recognise when it is linked into the server and make local calls back to its counterpart in the server. However I think this is pretty ugly and unnecessarily complicates qemu_internal which shouldn't care how it is linked. My thoughts on the long term solution ------------------------------------- I'd really like to see the qemu case not require a daemon. At the moment (AFAICS) the qemu daemon serves two purposes: (a) it keeps track of the monitor file descriptors of the existing qemu processes, and (b) it handles the networking stuff, basically starting and stopping dnsmasq[2]. (a) is easily handled, I think, by having qemu processes put their monitor sockets into a well-known directory. This has the other advantage that qemu processes can survive and continue after qemu programs restart. For the (b) case, I don't think networking which is a general service should be mixed up with qemu code. I think (although probably I've missed some things) that this means that qemu_internal could be implemented entirely as a local service, requiring no daemon. (In the case where qemu_internal needs to control a root-owned system-wide set of qemu processes then we'd still have to have a daemon, but it can be the remote daemon, same way that Xen will work). My suggestion for a short term solution --------------------------------------- Since doing the above is way more than I'm going to do just to get remote working, my suggestion is that we have two daemons running, qemud and remote. Both would be built from the exact same codebase: the mode would be selected by having a 'libvirtd --remote' flag on the command line (or however, but the important thing is that they'd keep the same codebase). This immediately fixes the deadlock problem[3] because qemu_internal linked to the server is now talking to a different daemon. Rich. [1] As an aside, I don't particularly like this architecture. Linus has handed down to us an efficient operating system which is already capable of multiplexing different clients using a marvellous system called "multitasking". Hand-coding polling code inside a single process is really only necessary in very limited circumstances, such as highly tuned uniprocessor machines with enormous loads, and we are not likely to get into such a situation with libvirtd. If we ever did we'd need to benchmark a range of possible solutions. Processes on the other hand have real advantages, such as security through isolation and controlled sharing, and easy scalability onto SMP machines. [2] Although I don't really understand the networking stuff too well, so perhaps it does other things. [3] Except in the "remote-on-remote" case, but we should disallow this explicitly because it seems like it would be nothing but trouble. -- 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] Community IRC chat room for virt management tools/APIs/protocols
by Daniel P. Berrange 19 Apr '07

19 Apr '07

At the Xen summit a number of us thought it would be a good idea to have an IRC chat room for people interested in technical discussions relating to hypervisor agnostic management tools / APIs / protocols. This includes libvirt, virt-manager, VNC extensions for virtualization, and more. Thus we decided to colonise the channel #virt on irc.oftc.net - feel free to come and join us.... 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 -=|

1 0

[Libvir] ia64 support
by Aron Griffis 18 Apr '07

18 Apr '07

Hi Daniel, Yesterday in your libvirt presentation at Xen Summit, you listed sparc and ppc as architectures with explicit support in libvirt. I looked through the code to see how to add ia64 to that list, but I'm not seeing much mention of sparc or ppc except in the qemud backend. Is there somewhere else I should be looking? Thanks, Aron

2 3

[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

[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