[libvirt] My beefs with the libvirt XML configuration format
Hello,
In a recent post on my blog [1] I ranted on about libvirt and in
particular I complained that the configuration files look like what I
call “almost XML”. The reasons why I say that are multiple, let me try
to explain some.
In the configuration files, at least those created by virt-manager there
is no specification of what the file should be (no document type, no
namespace, and, IMHO, a too generic root element name); given that some
kind of distinction is needed for software like Emacs's nxml-mode to
know how to deal with the file, I think that's pretty bad for
interaction between different applications. While libvirt knows
perfectly well what it's dealing with, other packages might not. Might
not sound a major issue but it starts tickling my senses when this
happens.
The configuration seem somewhat contrived in places like the disk
configuration: if the disk is file-backed it require the file attribute
to the <source> element, while it needs the dev attribute if it's a
block device; given that it's a path in both cases it would have sounded
easier on the user if a single path attribute was used. But this is
opinable.
The third problem I called out for in the block is a lack of a schema
for the files; Daniel corrected me pointing out that the schemas are
distributed with the sources and installed. Sure thing, I was wrong. On
the other hand I maintain that there are problems with those schemas.
The first is that both the version distributed with 0.7.4 and the git
version as of today suffer from bug #546254 [2] (secret.rng being not
well formed) so it means nobody has even tested them as of lately; then
there is the fact that they are never referenced by the human-readable
documentation [3] which is why I didn't find it the first time around;
add also to that some contrived syntax in those schema as well that
causes trang to produce a non-valid rnc file out of them (nxml-mode uses
rnc rather than rng).
But I guess the one big problem with the schemas is that they don't seem
to properly encode what the human-readable documentation says, or what
virt-manager does. For instance (please follow me with selector-like
syntax), virt-manager creates /domain/os/type[(a)machine='pc-0.11'] in the
created XML; the same attribute seem to be documented: “There are also
two optional attributes, arch specifying the CPU architecture to
virtualization, and machine referring to the machine type”. The schema
does not seem to accept that attribute though (“element type: Relax-NG
validity error : Invalid attribute machine for element type” with
xmllint, just to make sure that it's not a bug in any other piece of
software, this is Daniel's libxml2).
Now after voicing my opinions here, as Daniel dared me to do, I'd like
to explain a second why I didn't post this on the list in the first
place: of what I wrote here, my beefs for calling this aXML, the only
things that can be solved easily are the schemas; schemas that, at the
time I wrote the blog, I was unable to find. The syntax, and the lack of
a “safe” identification of the files as libvirt's are the kind of legacy
problems one has to deal with to avoid wasting users' time with
migrations and corrections, so I don't really think they should be
addressed unless a redesign of the configuration is intended.
Just my two cents, you're free to take them as you wish, I cannot boast
a curriculum like Daniel's, but I don't think I'm stepping out of place
to point out these things.
[1]
http://blog.flameeyes.eu/2009/12/07/i-know-you-missed-them-virtualisation...
[2] https://bugzilla.redhat.com/show_bug.cgi?id=546254
[3] http://libvirt.org/format.html
--
Diego Elio Pettenò — “Flameeyes”
http://blog.flameeyes.eu/
If you found a .asc file in this mail and know not what it is,
it's a GnuPG digital signature: http://www.gnupg.org/