July 2007 - Devel - libvirt List Archives

[Libvir] XML escaping patch
by Daniel Veillard 06 Jul '07

06 Jul '07

This is related to bug #206653 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=206653 basically we are very optimistic when generating the XML files, and sometimes this can break. The most common case is if some string inherited from the user input or some other config file embeds one of > < or & , another one would be if the strings are containing character outside of ACSII range and not encoded in UTF-8. We can at least cope with the easy case of escaping the 3 characters. This patch adds a simple buffer printing routing working with a simple string argument, and use it for the 2 cases where I think it's most likely to be needed i.e. cmdline and bootloader_args. There is a number of places where paths are used and the user might use weird character names, but since those cases can't be handled properly (you can't change that path or try to convert encoding on the fly since we can't guess reliably which one is used) I didn't tried to change those. This makes for a relatively simple patch which should IMHO cover most case where we may break while we really should not. 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/

3 7

[Libvir] Some doubts for OpenVZ
by Shuveb Hussain 06 Jul '07

06 Jul '07

Hi, I have some basic doubts. 1. The OpenVZ system has one config file per VM which contains all the VM's parameters. So, during libvirt start-up, these files can be read, or openvz utils can be popened() to get information regarding these VMs. Is there a necessity to have per-vm config files in libvirt for the OpenVZ VMs? I understand UUIDs are used to identify each of the running VMs. Where will these values persist? Can I do away with UUIDs for OpenVZ and avoid the libvirt specific config file? 2. In OpenVZ, there is just a VPS ID/Name. There is no temporary reference like 'id'. For example QEMU is using the process PID. There is no such notion for OpenVZ. In that case, can I make 'name' and 'id' same for OpenVZ? Thanks, -- Shuveb Hussain Unix is very user friendly. It is just a little choosy about who its friends are http://www.binarykarma.com

3 5

[Libvir] virsh vcpupin does not work with xend
by Saori Fukuta 06 Jul '07

06 Jul '07

Hi, The virsh vcpupin command does not work when it uses Xend(xend_internal.c). HV(xen_internal.c) works fine. I'm testing on Xen3.1.0(hypervisor_version=2, dom_interface_version=5, xendConfigVersion=4), and using current libvirt(ChangeLog revision 1.546). To solve this problem, I got the xend debug information and compared that. * in the case of executing "virsh vcpupin 63 7 1" * [2007-05-29 09:33:20 4258] DEBUG (XendDomain:1297) dom(63) cpu 7 cpumap [1](<type'str'>) * in the case of executing "xm vcpu-pin 63 7 1" * [2007-05-29 09:33:32 4258] DEBUG (XendDomain:1297) dom(63) cpu 7 cpumap [1](<type'list'>) There is one different thing. The type of cpumap is str when executing virsh command, but the type of cpumap is list when executing xm command. Do you have any idea ? Thanks, Saori Fukuta

2 4

[Libvir] LSBization of libvirt init script
by Daniel Veillard 06 Jul '07

06 Jul '07

Small patch applied to qemud/libvirtd.init.in: - adds an LSB compliant header - add a couple of LSB defined functions - fixes the name in the chkconfig comments Hopefully it's correct :-) 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/

2 2

[Libvir] [Q]Will virConnectNumOfNetworks and virConnectNumOfDefinedNetworks be supported by Xen ?
by S.Sakamoto 06 Jul '07

06 Jul '07

Hi, When I use virt-manager that is connected by xen, the following error is given at every monitoring. libvir: Error : this function is not supported by the hypervisor: virConnectNumOfNetworks libvir: Error : this function is not supported by the hypervisor: virConnectNumOfDefinedNetworks Therefore I have a question. Will virConnectNumOfNetworks and virConnectNumOfDefinedNetworks be supported by Xen ? When is it if supported ? Thanks, Shigeki Sakamoto.

4 8

Re: [Libvir] [RFC]OpenVZ XML def
by Richard W.M. Jones 05 Jul '07

05 Jul '07

Shuveb Hussain wrote: [...] OK, but still let us know if there are particular things which are a problem to parse. Also if you can just follow-up sometime with example output from OpenVZ commands. I'd like to see that, since I tried to get OpenVZ working on my machine, but it broke down (unrelated to OpenVZ :-) 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 05 Jul '07

05 Jul '07

Shuveb Hussain wrote: >> >> Daemon though? Can't the libvirt code just invoke the OpenVZ commands >> directly? > > Yeah, that is very much possible. But if it were a daemon, it could be > a Python daemon, since text processing is much simpler and I don't > have to use the str*( ) funcs in C. What is your comment? I'm a big advocate of using a sane language instead of C, but libvirt is written in C for better or worse. The problem with a separate daemon is management of that daemon. Something needs to start it and stop it, it needs to have sockets with the right permissions and so on. What happens if the process runs and can't find the daemon? What is the path to the socket? etc. etc. At the moment we have two daemons - the qemu daemon (which has two separate functions intertwined), and a remote daemon (necessary, because there's no other way to communicate to a remote machine). One idea would be to have the Python code fork off from the main program and communicate over a pipe. With this, there is no daemon management problem. +----------------+ | Program | | - - - - - - - -| | libvirt | +----------------+ | | fork(2) and pipe(2) | +-------------+ | Python code | +-------------+ But I'm not the person who ultimately decides what would be acceptable in libvirt. You'd need to get general agreement on the best way to do 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

3 7

[Libvir] [PATCH] virDomainLookup* functions raise VIR_ERR_NO_DOMAIN if the domain doesn't exist
by Richard W.M. Jones 04 Jul '07

04 Jul '07

The patches that I'm going to follow up with change virDomainLookup* functions so that they raise VIR_ERR_NO_DOMAIN where a domain doesn't exist (but there is no other error), else raise some other error where there's an actual error occuring. This will allow wrappers in other languages to distinguish the three cases found / not found / error. 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 20

[Libvir] [PATCH] Fix xm_internal configCache
by Richard W.M. Jones 04 Jul '07

04 Jul '07

This patch: (1) Fixes inactive domains over remote. The real cause of this error turned out to be that after configCache hash is created, the last refresh date wasn't reset, so a subsequent call to xenXMConfigCacheRefresh might not actually repopulate the cache. This only affects the remote case, because only in the remote case do we have a long running process (libvirtd) which closes and reopens xm_internal.c, so this code had never been exercised before. It also explains why the bug was annoyingly intermittent. If you wait >= 10 seconds during testing, then the cache does get refilled, so the bug is hidden. (2) Adds error messages to xenXMConfigCacheRefresh. (3) As Daniel Veillard suggested, change the obscure !nconnections-- condition to two explicit statements. (4) In xenXMOpen, change the condition from nconnections == 0 to configCache == NULL, to remove the implicit dependency between the two variables. 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] [PATCH] xend 404 errors return VIR_ERR_NO_DOMAIN
by Richard W.M. Jones 04 Jul '07

04 Jul '07

(1) Check for 404 errors from xend and turn them into VIR_ERR_NO_DOMAIN (currently they are VIR_ERR_POST_FAILED). You'll typically see this when you have a handle to a domain, but the underlying domain is shutdown, as in this example: $ python Python 2.4.3 (#1, Dec 11 2006, 11:39:03) [GCC 4.1.1 20061130 (Red Hat 4.1.1-43)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import libvirt >>> conn = libvirt.open ("xen+tls:///") >>> dom = conn.lookupByName ("fc6_6") >>> dom.suspend () 0 >>> dom.resume () 0 #### here, I shut down the domain using 'xm' >>> dom.suspend () libvir: Xen Daemon error : Domain not found: No such domain fc6_6 Traceback (most recent call last): File "<stdin>", line 1, in ? File "/home/rjones/local/lib/python2.4/site-packages/libvirt.py", line 359, in suspend if ret == -1: raise libvirtError ('virDomainSuspend() failed', dom=self) libvirt.libvirtError: virDomainSuspend() failed Domain not found: No such domain fc6_6 (2) There was a case where xend was returning an error, but we didn't translate that into an error return code (-1). I'm sure this is an oversight, and the patch fixes it. 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