9:18 a.m.
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/
9:23 a.m.
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/
2:10 p.m.
On 10/02/2010 10:23 AM, Richard W.M. Jones wrote:
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.
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(a)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);
}
3:09 p.m.
2010/10/2 Richard W.M. Jones <rjones(a)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
4:33 a.m.
On Sat, Oct 02, 2010 at 10:09:31PM +0200, Matthias Bolte wrote:
2010/10/2 Richard W.M. Jones <rjones(a)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
7:51 a.m.
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. :(
1:38 a.m.
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(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
1:55 a.m.
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)
5:59 a.m.
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(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
5:35 a.m.
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
11:03 a.m.
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
11:31 a.m.
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. :)
5:26 a.m.
New subject: [libvirt] Test results (was: Re: Valid characters in domain names?)
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/
5:48 a.m.
New subject: [libvirt] Test results
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
5:41 a.m.
New subject: [libvirt] Test results (was: Re: Valid characters in domain names?)
*** <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
6:07 a.m.
New subject: [libvirt] Test results (was: Re: Valid characters in domain names?)
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(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
6:40 a.m.
New subject: [libvirt] Test results (was: Re: Valid characters in domain names?)
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
6:44 a.m.
New subject: [libvirt] Test results (was: Re: Valid characters in domain names?)
> 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/
7:50 a.m.
New subject: [libvirt] Test results
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.
8:48 a.m.
New subject: [libvirt] Test results (was: Re: Valid characters in domain names?)
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
10:27 a.m.
New subject: [libvirt] Test results (was: Re: Valid characters in domain names?)
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
7:05 a.m.
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
9:23 a.m.
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
5111
days inactive
5165
days old
24 comments
8 participants
participants (8)
-
Daniel Veillard -
Justin Clift -
Marcin Szewczyk -
Marcin Szewczyk -
Matthias Bolte -
Paolo Bonzini -
Richard W.M. Jones -
Stefan Berger