[Libvir] Semantics for ListDomains/ ListDefinedDomains
Daniel Veillard
veillard at redhat.com
Wed Aug 23 21:15:26 UTC 2006
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/
More information about the libvir-list
mailing list