Re: [libvirt] My beefs with the libvirt XML configuration format
On Thu, Dec 10, 2009 at 06:07:13PM +0000, Daniel P. Berrange wrote:
On Thu, Dec 10, 2009 at 05:49:39PM +0000, Richard W.M. Jones wrote:
> On Thu, Dec 10, 2009 at 05:44:43PM +0100, Daniel Veillard wrote:
> > Your viewpoint is that users should edit the XML. My viewpoint is that
> > software should do this, basically in normal use of libvirt nobody
> > should have to look at the XML, the virt-viewer/virt-install etc...
> > tools should generate and handle those for you. It happens that one may
> > have to tweak something like a pathname in a definition or something but
> > whatever the level of schemas available it won't help for that kind of
> > tweaks. Things like changing the ethernet type adapter should be a
> > pull down list in a gui like virt-manager, not loading the saved xml in
> > emacs, finding the associated relax-ng, finding the place where it's
> > defined and hoping emacs will get a list to pick from,
>
> I edit libvirt XML all the time. The 'virsh edit' command is most
> useful ...
>
> I'd like to add my own rant about this though:
>
> If an element isn't understood by libvirt, then libvirt just discards
> it (without any indication or error, and without just remembering the
> element in the XML).
Remembering is a hard feature and probably not worth it in libvirt
case (but I'm sure I argued with dan over this at the very beginning :-)
it makes sense for editor like applications or when you know you need
to mix vocabularies, for libvirt, I think it's overkill and would
make the code significantly more complex.
There should be an option to validate the XML input, either by
providing a VIR_DOMAIN_XML_VALIDATE flag with the APIs which
accept XML as input, or by having virsh edit doing validation
after the editor exits.
I think I suggested a couple of time to have the input XML data
be validated at the API level, but we don't want to do this
systematically, this would create IMHO more problems it can solve.
Using a flag and/or activating it when libvirt conf is in debug mode
would both make sense.
This would also allow virsh to re-launch the editor upon error
and let you correct the mistake instead of forcing you to start
again from scratch.
The schemas validation won't be perfect in any way, for example
trying to limit the list of allowed ethernet adapter based on the
hypervisor type is nearly impossible even with Relax-NG since we
differentiate based on an attribute in the top level element (this
would force to basically write parallel schemas and become completely
unmaintainable). Relax-NG validation also will provide out of context
error messages, while the conf parser can give way better diagnostics.
> This caused me a great deal of pain yesterday when I was adding
a
> <watchdog/> element to a domain on an F12 machine, but the watchdog
> didn't appear in the VM. Later I discovered that libvirt on F12
> predates the watchdog feature, and so it was just tossing away the
> <watchdog/> element completely from the XML ...
It is good that it throws away unknown elements. Having settings in
the XML that are used, but which might suddenly become active with
any upgrade is not good for ensuring a stable ABI for the guest.
> > which even if you did it right might just not work because the
> > domain is running and your change would be discarded on
> > restart... oops.
That is not correct actually. It is possible with many of the drivers
(Xen, QEMU, LXC, UML) to change the persistent config, regardless of
whether the domain is running.
I used that as an example, the point being that decoupling the config
modification process from the actual application using the definition
makes some mistakes uncheckable either at the system level or even at
teh syntactic level, to take again the example of changing the ethernet
adapter while a specific tool like virt-manager may have the logic
needed to be able to provide a list based on the hypervisor type,
the Relax-NG will never embbed that logic.
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/