- Devel - libvirt List Archives

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