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.
* 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;file=xeninst/ParaVirtGuest.py
--
|=- 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 -=|