[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] My beefs with the libvirt XML configuration format



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

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. 

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.

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

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]