[Libvir] Semantics for ListDomains/ ListDefinedDomains

[Daniel Veillard]

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 at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/