Re: [Libvir] Semantics for ListDomains/ ListDefinedDomains

On Wed, Aug 23, 2006 at 02:21:03PM -0400, Daniel Veillard wrote: Ok, that makes sense - although means there's a bug in test backend :-) Trouble is I think we really badly need an implementation that is persistent. Tools like the 'xeninst[1]' package are using libvirt for creating domains, but at the same time manually writing out config files into /etc/xen - this means they are loosing an important benefit of libvirt - namely isolation from Xen instability/changes. Now it would be pretty easy for libvirt to convert the XML file passed into virDefineDomain into a config file for xend & stuf it in /etc/xen The hard part is the reverse - enumerating the config files in the dir & turning them back into XML. I fear we may have to tackle that hard part sooner rather than later so I've been trying to thing of ways we could attack it. Now the key problem is that the xm config files can contain/are in fact python code. * Write a tiny parser for a trivial subset - basically enough to handle the (key, string) pairs & (key, list of string) pairs. Certainly doable - depending on how general purpose we want to get - do we care about the 'if..else' conditional used in the sample /etc/xen/xmexample.vti config file ? We can certainly make a valid case saying we don't care about this because the libvirt XML -> xm config conversion would not generate config using that capability * Fork an unprivileged helper python program to exec the config file and re-write it as XML which can be read back in by libvirt The former is more work, but makes me feel better from a security point of view. The latter is more genreal purpose but a small slip up could have big consequences. My personal preference would be the first option & say 'if...else' is unsupported for now Not a perfect solution, but would satisfy a great deal of common use cases pretty easily without being intrusive into existing code base & pretty secure. Regards, Dan. [1] see '_get_xen_config' method, line 140 http://hg.et.redhat.com/virt/applications/xeninst--devel?f=d21d927fd7c4;f... -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|