- Devel - libvirt List Archives

[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