[libvirt] My beefs with the libvirt XML configuration format

[Cole Robinson]

On 12/10/2009 10:51 AM, Diego Elio “Flameeyes” Pettenò wrote:
> 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.
> 

This is something that has always bugged me as well, and is indeed a
pain to deal with in virt-manager when doing things like changing cdrom
media. I think we should just loosen the input restrictions, so that any
path passed via the <source> properties file, dev, or dir are used, but
will be dumped with the 'correct' property to maintain back compat.

That said, I think the XML format is pretty straight forward. The above
caveat you mention is the only real annoying thing. The one other
stumbling block is that not all devices have a unique property to key
off of in the XML (ex. you can have two identical <video> devices). This
makes life difficult for virt-manager when removing a device, but it
hasn't been a big issue in practice.

> 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).
> 

The bug you mention only exists because we don't have secret XML
regression tests. Other schemas are in better shape: I'm pretty
confident that virtual network and storage pool/volume schemas have near
complete coverage. Domain probably has very high coverage but there are
no doubt nuances of the format that aren't covered by our regression
suite, and therefor may have incorrect schemas.

For a long while we didn't use the XML schemas for anything so they were
horrendously out of date and practically useless. That has changed
within the past year but we are still playing catchup to have the schema
match libvirt code reality.

Putting a link to schemas on the website is also a good idea.

> 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[@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).
> 

If there are any other pieces of the schema that you find are incorrect
or don't match reality, please enumerate them here and I'll take some
time to make sure they are tested in our regression suite.

Thanks,
Cole