- Devel - libvirt List Archives

[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