[libvirt] Valid characters in domain names?
Does libvirt enforce any sort of validity of characters in guest names? Someone tried to create a domain called '#' (the single hash character) and noted that this caused failures in virt-tools: https://bugzilla.redhat.com/show_bug.cgi?id=639601 https://bugzilla.redhat.com/show_bug.cgi?id=639602 Had a look at the code but couldn't see anything obvious: It seems like libvirt delegates this entirely to the drivers, the drivers (probably) all call virDomainDefParseXML, and this function does no checking that I could see. If my analysis is correct, this could be dangerous. What if the name contains a character that is special to the qemu command line (','), to XML ('>'), or to C (�)? As an example, the code already does: char *virDomainDefFormat(virDomainDefPtr def, int flags) { ... virBufferEscapeString(&buf, " <name>%s</name>\n", def->name); ... } Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/
On Sat, Oct 02, 2010 at 03:18:30PM +0100, Richard W.M. Jones wrote:
virBufferEscapeString(&buf, " <name>%s</name>\n", def->name);
I see this example is safe because virBufferEscapeString escapes the parameter. Sure there are still problems with a domain called "," or "/" though. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/
On 10/02/2010 10:23 AM, Richard W.M. Jones wrote:
virBufferEscapeString(&buf, "<name>%s</name>\n", def->name); I see this example is safe because virBufferEscapeString escapes the
On Sat, Oct 02, 2010 at 03:18:30PM +0100, Richard W.M. Jones wrote: parameter. Sure there are still problems with a domain called "," or "/" though.
Rich.
Defining a VM with ';' in the names seems to work, but starting it using 'virsh' is a challenge... To address the problems with "," and "/" I'd put the defenses into the qemu driver, assuming that other drivers may (or may not!) be able to deal with these characters. So here's a patch for qemu: Signed-off-by: Stefan Berger <stefanb@us.ibm.com> Index: libvirt-acl/src/qemu/qemu_conf.c =================================================================== --- libvirt-acl.orig/src/qemu/qemu_conf.c +++ libvirt-acl/src/qemu/qemu_conf.c @@ -3920,6 +3920,11 @@ int qemudBuildCommandLine(virConnectPtr ADD_ARG(smp); if (qemuCmdFlags & QEMUD_CMD_FLAG_NAME) { + if (def->name[strcspn(def->name, ",#")] != 0) { + qemuReportError(VIR_ERR_INTERNAL_ERROR, + _("VM name contains illegal character ('#', ',')")); + goto error; + } ADD_ARG_LIT("-name"); ADD_ARG_LIT(def->name); }
2010/10/2 Richard W.M. Jones <rjones@redhat.com>:
Does libvirt enforce any sort of validity of characters in guest names?
Someone tried to create a domain called '#' (the single hash character) and noted that this caused failures in virt-tools:
https://bugzilla.redhat.com/show_bug.cgi?id=639601 https://bugzilla.redhat.com/show_bug.cgi?id=639602
Had a look at the code but couldn't see anything obvious: It seems like libvirt delegates this entirely to the drivers, the drivers (probably) all call virDomainDefParseXML, and this function does no checking that I could see.
If my analysis is correct, this could be dangerous. What if the name contains a character that is special to the qemu command line (','), to XML ('>'), or to C (�)?
Actually there are more places in libvirt that are prone to certain characters in the domain name. The domain name is used as part of a file name in several places. For example per-domain log files in /var/log/libvirt/*/<domain name>.log will have trouble with a / in the domain name. Matthias
On Sat, Oct 02, 2010 at 10:09:31PM +0200, Matthias Bolte wrote:
2010/10/2 Richard W.M. Jones <rjones@redhat.com>:
Does libvirt enforce any sort of validity of characters in guest names?
Someone tried to create a domain called '#' (the single hash character) and noted that this caused failures in virt-tools:
https://bugzilla.redhat.com/show_bug.cgi?id=639601 https://bugzilla.redhat.com/show_bug.cgi?id=639602
Had a look at the code but couldn't see anything obvious: It seems like libvirt delegates this entirely to the drivers, the drivers (probably) all call virDomainDefParseXML, and this function does no checking that I could see.
If my analysis is correct, this could be dangerous. What if the name contains a character that is special to the qemu command line (','), to XML ('>'), or to C (�)?
Actually there are more places in libvirt that are prone to certain characters in the domain name. The domain name is used as part of a file name in several places. For example per-domain log files in /var/log/libvirt/*/<domain name>.log will have trouble with a / in the domain name.
Indeed. I'm sure we need a whitelist, not a blacklist as suggested by the other comment. All domains I'd ever want to create would match the regexp ^[[:alpha:]][-_[:alnum:]]*$ This might break existing users however. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://et.redhat.com/~rjones/libguestfs/ See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html
On 10/03/2010 08:33 PM, Richard W.M. Jones wrote: <snip>
Indeed. I'm sure we need a whitelist, not a blacklist as suggested by the other comment. All domains I'd ever want to create would match the regexp
^[[:alpha:]][-_[:alnum:]]*$
This might break existing users however.
Wonder if there are characters supported by some hypervisors, but not others? ie maybe Xen supports '/', '*', '+' in guest names, but ESX doesn't That could lead to some interesting guest import problems. :(
On Sun, Oct 03, 2010 at 11:51:12PM +1100, Justin Clift wrote:
On 10/03/2010 08:33 PM, Richard W.M. Jones wrote: <snip>
Indeed. I'm sure we need a whitelist, not a blacklist as suggested by the other comment. All domains I'd ever want to create would match the regexp
^[[:alpha:]][-_[:alnum:]]*$
This might break existing users however.
Wonder if there are characters supported by some hypervisors, but not others?
I remember we had troubles with Xen, a long time ago, yes So unfortunately this is really hypervsor specific... Maybe we could have a generic checking routine but only providing a warning when the name isn't a simple name the XML way. One of the problem of the checking too is that most of the hypervisor APIs don't say a word about encoding, so you're not manipulating characters but 0 terminated byte strings. From there even your simple regexp goes havoc because what is an alphanumeric character, requires character analysis and you need the encoding for this. At least at libvirt API things are rather clear, in XML data there is no ambiguity possible, and outside we expect strings to be UTF-8. Actually I think that for ESX since all exchanges with the hypervisor are XML based there isn't that ambiguity about encoding at least.
ie maybe Xen supports '/', '*', '+' in guest names, but ESX doesn't
That could lead to some interesting guest import problems. :(
goes beyond that, someone using any non-ascii name will hit hypervisor specific behaviour, ISO-Latin, asian language ... and we habe no control over this except for some checking and the possibility of a warning. Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
On 10/04/2010 05:38 PM, Daniel Veillard wrote: <snip>
Actually I think that for ESX since all exchanges with the hypervisor are XML based there isn't that ambiguity about encoding at least.
Yeah. vSphere has a fairly international market, so expecting they'd have a way of doing things by now to make sure this isn't a problem.
goes beyond that, someone using any non-ascii name will hit hypervisor specific behaviour, ISO-Latin, asian language ... and we habe no control over this except for some checking and the possibility of a warning.
Wonder what the best approach will be. Maybe a whitelist on "known good" characters, and a conversion table for situations where we need to proceed anyway? (if that happens)
On Mon, Oct 04, 2010 at 05:55:56PM +1100, Justin Clift wrote:
On 10/04/2010 05:38 PM, Daniel Veillard wrote:
goes beyond that, someone using any non-ascii name will hit hypervisor specific behaviour, ISO-Latin, asian language ... and we habe no control over this except for some checking and the possibility of a warning.
Wonder what the best approach will be. Maybe a whitelist on "known good" characters, and a conversion table for situations where we need to proceed anyway? (if that happens)
Well I don't think there is a good solution. Best is to warn the user and allow him to recover if possible. Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
On Mon, Oct 04, 2010 at 08:38:57AM +0200, Daniel Veillard wrote:
On Sun, Oct 03, 2010 at 11:51:12PM +1100, Justin Clift wrote:
On 10/03/2010 08:33 PM, Richard W.M. Jones wrote: <snip>
Indeed. I'm sure we need a whitelist, not a blacklist as suggested by the other comment. All domains I'd ever want to create would match the regexp
^[[:alpha:]][-_[:alnum:]]*$
This might break existing users however.
Wonder if there are characters supported by some hypervisors, but not others?
I remember we had troubles with Xen, a long time ago, yes So unfortunately this is really hypervsor specific... Maybe we could have a generic checking routine but only providing a warning when the name isn't a simple name the XML way. One of the problem of the checking too is that most of the hypervisor APIs don't say a word about encoding, so you're not manipulating characters but 0 terminated byte strings. From there even your simple regexp goes havoc because what is an alphanumeric character, requires character analysis and you need the encoding for this. At least at libvirt API things are rather clear, in XML data there is no ambiguity possible, and outside we expect strings to be UTF-8. Actually I think that for ESX since all exchanges with the hypervisor are XML based there isn't that ambiguity about encoding at least.
ie maybe Xen supports '/', '*', '+' in guest names, but ESX doesn't
That could lead to some interesting guest import problems. :(
goes beyond that, someone using any non-ascii name will hit hypervisor specific behaviour, ISO-Latin, asian language ... and we habe no control over this except for some checking and the possibility of a warning.
I think any reasonable analysis of this should start with where the names come from: - virDomainDefineXML (eg. virsh define, virt-install, V2V import etc) - a list of existing domains from a hypervisor API (eg. /etc/xen files, Xen hypercall, ESX XMLRPC call) - already defined in an older version of libvirt which didn't do checking - [any others?] For the virDomainDefineXML route, we (a) know the names are UTF-8, and (b) know that these domains are being created for the first time. And I think for this route we should add a regexp-like restriction. (Note when I wrote [:alnum:] before, that ought to cover all Unicode characters in the alphanumeric classes, so it doesn't exclude non-US characters). There are further points that may need to be fixed within the drivers. The drivers are probably just passing the UTF-8 strings through to everything, but may need to do conversion. eg. If I've learned anything about Microsoft developers, then a hypothetical Hyper-V driver would almost certainly need to convert between UTF-8 and UTF-16LE. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v
On 10/03/2010 11:33 AM, Richard W.M. Jones wrote:
Indeed. I'm sure we need a whitelist, not a blacklist as suggested by the other comment. All domains I'd ever want to create would match the regexp
^[[:alpha:]][-_[:alnum:]]*$
This might break existing users however.
A period in a name is definitely useful. Also, I think there is no need to differentiate between the first and the other characters, except perhaps to prohibit a name starting with "-". Paolo
On 10/05/2010 03:03 AM, Paolo Bonzini wrote:
On 10/03/2010 11:33 AM, Richard W.M. Jones wrote:
Indeed. I'm sure we need a whitelist, not a blacklist as suggested by the other comment. All domains I'd ever want to create would match the regexp
^[[:alpha:]][-_[:alnum:]]*$
This might break existing users however.
A period in a name is definitely useful. Also, I think there is no need to differentiate between the first and the other characters, except perhaps to prohibit a name starting with "-".
Heh. Two periods in a name could lead to fun. Stuff like: name="../../../etc/shadow" Well, you know what I mean. :)
I tried creating several KVM domains with non-alnum names to see what actually happens. The names as shown here are XML-encoded, ie. they are how they appear in the libvirt domain XML. *** <name>�</name> *** libvirt prevents me from defining this domain, with the following error: error: Failed to define domain from /tmp/chars.xml error: at line 2: xmlParseCharRef: invalid xmlChar value 0 Am I specifying the XML correctly? *** <name>#</name> *** virsh define - OK virsh list - OK virsh start - OK virt-viewer - OK virt-df - OK virsh destroy - OK virt-list-filesystems - OK Conclusion: RHBZ#639601 and RHBZ#639602 are just user error. The reporter is typing something like: virt-list-filesystems # but the shell takes the # character as a comment. If instead you do: virt-list-filesystems '#' or virt-list-filesystems \# then it works fine. *** <name>,</name> *** virsh define - OK virsh list - OK virsh start - FAILED virt-viewer - n/a virt-df - OK virsh destroy - n/a virt-list-filesystems - OK virsh start failed with the error: error: Failed to start domain , error: internal error process exited while connecting to monitor: Unknown subargument to -name This looks like a real bug. The qemu driver should prevent domains from being created that contain characters that are special for the qemu command line. *** <name>></name> *** virsh define - OK virsh list - OK virsh start - OK virt-viewer - OK virt-df - OK virsh destroy - OK virt-list-filesystems - OK *** <name>変な</name> *** virsh define - OK virsh list - see below virsh start - OK virt-viewer - OK virt-df - OK virsh destroy - OK virt-list-filesystems - OK 'virsh list' command is fine, except the 'State' columns don't line up because these two characters are wide chars. You see something like this: - Win7x32 shut off - [][] shut off *** <name>/</name> *** virsh define - OK virsh list - OK virsh start - see below virt-viewer - OK virt-df - FAILED virsh destroy - OK virt-list-filesystems - FAILED The domain starts OK, but the log file is created as "/var/log/libvirt/qemu/.log". This is a bug, although sort of to be expected. virt-df and virt-list-filesystems both failed. This was because these programs use a heuristic to determine if the parameter passed is a libvirt domain name or a local disk image file. Because "/" looks (a bit) like a local file, it tries to open it as such and fails. The error message is: qemu: could not open disk image /: Is a directory unexpected end of file when reading from daemon at /usr/bin/virt-list-filesystems line 131. I think realistically libvirt should prevent domains with / anywhere in the name from being defined. *** <name>:</name> *** virsh define - OK virsh list - OK virsh start - OK virt-viewer - OK virt-df - OK virsh destroy - OK virt-list-filesystems - OK * * * I will file bugs for the above issues. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/
On Mon, Oct 04, 2010 at 09:35:35PM +1100, Justin Clift wrote:
On 10/04/2010 09:26 PM, Richard W.M. Jones wrote:
I tried creating several KVM domains with non-alnum names to see what actually happens.
You forgot to mention which version of libvirt and KVM you're testing against?
Indeed I did forget. It is: libvirt-0.8.3-2.fc14.x86_64 qemu-0.13.0-0.7.rc1.fc14.x86_64 Pretty much the latest or almost the latest in Fedora 14. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top
*** <name>a/b</name> *** virsh define - FAILED error: Failed to define domain from /tmp/chars.xml error: cannot create config file '/etc/libvirt/qemu/a/b.xml': No such file or directory Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
On Mon, Oct 04, 2010 at 11:26:32AM +0100, Richard W.M. Jones wrote:
I tried creating several KVM domains with non-alnum names to see what actually happens.
The names as shown here are XML-encoded, ie. they are how they appear in the libvirt domain XML.
*** <name>�</name> ***
libvirt prevents me from defining this domain, with the following error:
error: Failed to define domain from /tmp/chars.xml error: at line 2: xmlParseCharRef: invalid xmlChar value 0
Am I specifying the XML correctly?
Forbidden character in XML, we just can't use this. http://www.w3.org/TR/REC-xml/#NT-Char defines the allowed character ranges, bizarre control characters from start of ASCII are forbidden not just 0, surrogates and values usually used as Byte Order Mark are also excluded. And this is a Good Thing (TM) :-)
*** <name>#</name> ***
virsh define - OK virsh list - OK virsh start - OK virt-viewer - OK virt-df - OK virsh destroy - OK virt-list-filesystems - OK
assuming a QEmu/KVM guest, right ?
Conclusion: RHBZ#639601 and RHBZ#639602 are just user error. The reporter is typing something like:
virt-list-filesystems #
but the shell takes the # character as a comment. If instead you do:
virt-list-filesystems '#'
or
virt-list-filesystems \#
then it works fine.
*** <name>,</name> ***
virsh define - OK virsh list - OK virsh start - FAILED virt-viewer - n/a virt-df - OK virsh destroy - n/a virt-list-filesystems - OK
virsh start failed with the error:
error: Failed to start domain , error: internal error process exited while connecting to monitor: Unknown subargument to -name
This looks like a real bug. The qemu driver should prevent domains from being created that contain characters that are special for the qemu command line.
okay, we should make a bug
*** <name>></name> ***
virsh define - OK virsh list - OK virsh start - OK virt-viewer - OK virt-df - OK virsh destroy - OK virt-list-filesystems - OK
I'm rather surprized this didn't break qemu execution, interesting...
*** <name>変な</name> ***
virsh define - OK virsh list - see below virsh start - OK virt-viewer - OK virt-df - OK virsh destroy - OK virt-list-filesystems - OK
'virsh list' command is fine, except the 'State' columns don't line up because these two characters are wide chars. You see something like this:
- Win7x32 shut off - [][] shut off
minor really, I would count this as a pass,
*** <name>/</name> ***
virsh define - OK virsh list - OK virsh start - see below virt-viewer - OK virt-df - FAILED virsh destroy - OK virt-list-filesystems - FAILED
The domain starts OK, but the log file is created as "/var/log/libvirt/qemu/.log". This is a bug, although sort of to be expected.
virt-df and virt-list-filesystems both failed. This was because these programs use a heuristic to determine if the parameter passed is a libvirt domain name or a local disk image file. Because "/" looks (a bit) like a local file, it tries to open it as such and fails. The error message is:
qemu: could not open disk image /: Is a directory unexpected end of file when reading from daemon at /usr/bin/virt-list-filesystems line 131.
I think realistically libvirt should prevent domains with / anywhere in the name from being defined.
at least for QEmu, yes
*** <name>:</name> ***
virsh define - OK virsh list - OK virsh start - OK virt-viewer - OK virt-df - OK virsh destroy - OK virt-list-filesystems - OK
Thanks for doing this, we actually did better than I expected :-) Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
On Mon, Oct 04, 2010 at 01:07:40PM +0200, Daniel Veillard wrote:
assuming a QEmu/KVM guest, right ?
Yes.
virsh start failed with the error:
error: Failed to start domain , error: internal error process exited while connecting to monitor: Unknown subargument to -name
This looks like a real bug. The qemu driver should prevent domains from being created that contain characters that are special for the qemu command line.
okay, we should make a bug
Already done: https://bugzilla.redhat.com/show_bug.cgi?id=639926
qemu: could not open disk image /: Is a directory unexpected end of file when reading from daemon at /usr/bin/virt-list-filesystems line 131.
I think realistically libvirt should prevent domains with / anywhere in the name from being defined.
at least for QEmu, yes
https://bugzilla.redhat.com/show_bug.cgi?id=639923 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top
I think realistically libvirt should prevent domains with / anywhere in the name from being defined.
at least for QEmu, yes
Also, Justin Clift raised with me the issue of what happens if someone creates a domain called 'autostart/foo.xml' or 'networks/foo.xml' or 'networks/autostart/foo.xml'. The configuration files for these would work and overwrite special paths under /etc/libvirt/qemu. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/
On 10/04/2010 07:44 AM, Richard W.M. Jones wrote:
I think realistically libvirt should prevent domains with / anywhere in the name from being defined. at least for QEmu, yes Also, Justin Clift raised with me the issue of what happens if someone creates a domain called 'autostart/foo.xml' or 'networks/foo.xml' or 'networks/autostart/foo.xml'. The configuration files for these would work and overwrite special paths under /etc/libvirt/qemu.
It looks like a domain (and likely anything else that has a 'name') whose name contains a ';' or spaces is unaccessible from virsh unless one finds out the uuid ,which only root can do(?). Probably this is only a problem when using virsh, but maybe the user should be given the choice to delete the VM (in that special case) or at least also display its uuid upon 'virsh define/create' so he has a chance to actually use/delete it. Stefan
Rich.
A few more: *** <name>"</name> *** virsh define - OK virsh list - OK virsh start - FAILED virt-viewer - n/a virt-df - see below virsh destroy - n/a virt-list-filesystems - OK I'm fairly sure this is not a shell error: $ sudo virsh start \" error: missing " https://bugzilla.redhat.com/show_bug.cgi?id=639983 virt-df is fine, but virt-df --csv doesn't properly quote the output. https://bugzilla.redhat.com/show_bug.cgi?id=639986 *** <name>;</name> *** virsh define - OK virsh list - OK virsh start - FAILED virt-viewer - n/a virt-df - OK virsh destroy - n/a virt-list-filesystems - OK I'm fairly sure this is not a shell error: $ sudo virsh start \; error: command 'start' requires <domain> option $ sudo virsh start ';' error: command 'start' requires <domain> option I thought it might be a problem with sudo, so I also tried: $ su # virsh start ';' error: command 'start' requires <domain> option https://bugzilla.redhat.com/show_bug.cgi?id=639987 *** <name>\</name> *** virsh define - OK virsh list - OK virsh start - OK virt-viewer - OK virt-df - OK virsh destroy - OK virt-list-filesystems - OK *** <name>|</name> *** virsh define - OK virsh list - OK virsh start - OK virt-viewer - OK virt-df - OK virsh destroy - OK virt-list-filesystems - OK Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top
There are also some obvious ones I missed before: *** <name>-</name> *** virsh define - OK virsh list - OK virsh start - OK virt-viewer - OK virt-df - OK virsh destroy - OK virt-list-filesystems - OK Note to start it you need: sudo virsh -- start - For virt-df you need: sudo virt-df -- - and similarly for other virt tools. The qemu command line is: /usr/bin/qemu-kvm -S -M fedora-13 -enable-kvm -m 256 -smp 1,sockets=1,cores=1,threads=1 -name - -uuid [...] which I was a bit surprised by. I guess qemu's command line parsing is quite ad hoc. *** <name> </name> *** error: Failed to define domain from /tmp/chars.xml error: at line 2: Entity 'nbsp' not defined *** <name> </name> *** Note that U+00A0 is Unicode non-breaking space. virsh define - OK(!) virsh list - OK(!) virsh start - OK(!) virt-viewer - OK(!) virt-df - OK(!) virsh destroy - OK(!) virt-list-filesystems - OK(!) This is very surprising, but it all does work. $ sudo virsh destroy ' ' Domain destroyed $ sudo virt-df ' ' Filesystem 1K-blocks Used Available Use% :/dev/sda1 31725 396 29691 2% Let's go a step further down this whitespace road: *** <name> </name> *** virsh define - OK(!) virsh list - OK(!) virsh start - FAILED virt-viewer - n/a virt-df - OK(!) virsh destroy - n/a virt-list-filesystems - OK(!) $ sudo virsh start ' ' error: command 'start' requires <domain> option $ sudo virt-df ' ' Filesystem 1K-blocks Used Available Use% :/dev/sda1 31725 396 29691 2% *** <name></name> *** virsh define - OK virsh list - OK virsh start - OK virt-viewer - OK virt-df - OK virsh destroy - OK virt-list-filesystems - OK This one is tricky to test. You can't type or copy this character. However if you create a file containing this character then you can do: $ sudo virsh start $(cat /tmp/del) Domain started etc and I was able to verify that all the commands above work fine. I haven't filed any more bugs for these ones. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://et.redhat.com/~rjones/libguestfs/ See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html
I would like to associate this discussion with a bug I've submitted to Ubuntu's Launchpad... https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/672948 Inconsistent XML config checks for domains with space in the name 1) http://libvirt.org/formatdomain.html#elementsMetadata states: "This name should consist only of alpha-numeric characters". 2) /usr/share/libvirt/schemas/domain.rng: <element name="name"> <ref name="domainName"/> </element> <define name="domainName"> <data type="string"> <param name="pattern">[A-Za-z0-9_\.\+\-&:/]+</param> </data> </define> 3) Virsh accepts <name> with spaces, but then during a vm start some misguiding output is generated. It says aa_change_profile() fails. Virsh doesn't check the config with the schema as well. libvirt-bin 0.7.5-5ubuntu27.7 -- Marcin Szewczyk http://wodny.org mailto:Marcin.Szewczyk@wodny.borg <- remove b / usuń b xmpp:wodny@ubuntu.pl xmpp:wodny@jabster.pl
I would like to add my bug report to the discussion: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/672948 -- Marcin Szewczyk http://wodny.org mailto:Marcin.Szewczyk@wodny.borg <- remove b / usuń b xmpp:wodny@ubuntu.pl xmpp:wodny@jabster.pl
participants (8)
-
Daniel Veillard -
Justin Clift -
Marcin Szewczyk -
Marcin Szewczyk -
Matthias Bolte -
Paolo Bonzini -
Richard W.M. Jones -
Stefan Berger