[Libvir] XML escaping patch
by Daniel Veillard
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/
17 years, 3 months
[Libvir] Some doubts for OpenVZ
by Shuveb Hussain
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
17 years, 3 months
[Libvir] virsh vcpupin does not work with xend
by Saori Fukuta
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
17 years, 3 months
[Libvir] [Q]Will virConnectNumOfNetworks and virConnectNumOfDefinedNetworks be supported by Xen ?
by S.Sakamoto
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.
17 years, 3 months
Re: [Libvir] [RFC]OpenVZ XML def
by Richard W.M. Jones
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
17 years, 3 months
Re: [Libvir] [RFC]OpenVZ XML def
by Richard W.M. Jones
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
17 years, 3 months
[Libvir] [PATCH] virDomainLookup* functions raise VIR_ERR_NO_DOMAIN if the domain doesn't exist
by Richard W.M. Jones
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
17 years, 3 months
[Libvir] [PATCH] Fix xm_internal configCache
by Richard W.M. Jones
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
17 years, 3 months
[Libvir] [PATCH] xend 404 errors return VIR_ERR_NO_DOMAIN
by Richard W.M. Jones
(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
17 years, 3 months
