On Wed, Aug 23, 2006 at 09:22:08PM +0100, Daniel P. Berrange wrote: > On Wed, Aug 23, 2006 at 02:21:03PM -0400, Daniel Veillard wrote: > > On Wed, Aug 23, 2006 at 07:16:45PM +0100, Daniel P. Berrange wrote: > > > So I was thinking a little about lifecycle support for passive domains in > > > libvirt and wanted to clarify the intended semantics of the two methods: > > > > > > virConnectListDomains > > > virConnectListDefinedDomains > > > > > > Am I correct in thinking that virConnectListDefinedDomains will list a > > > domain if-and-only-if its state == 'shutoff', and that virConnectListDomains > > > will list a domain if-and-only-if its state != 'shutoff' > > > > yes > > Ok, that makes sense - although means there's a bug in test backend :-) > > > > I realize this is a little hypothetical since XenD doesn't have lifecycle > > > management yet, but it matters to the test backend, and any potential > > > QEMU / UML backend, and the future XenD XML-RPC backend > > > > I was tempted to do an implementation just local to the library instance > > in the case there is no support by the virtualization engine. If you think > > you will use it then I should really implement it :-) > > 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. I could see a problem with random apps writing to /etc/ , even if run as root that won't fly in general. But well if the goal is compatibility with existing xen tools, that may be a sufficient reason. > * 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 I'm not too concerned by handling only a subset, this should be data and processed as such IMHO. > * 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. Writing a parser doesn't frighten me too much :-) > 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 and import, and .... > 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. We are basically in agreement :-) So I write that parser ? Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/