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@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list