[Libvir] Semantics for ListDomains/ ListDefinedDomains

Thu Aug 24 02:04:17 UTC 2006

Pragmatically, I think a simple parser that only handles simple xm config
files would probably be fine 98% of the time, especially if you expect in
most situations the VMs will be created via libvirt anyway. The issue for
us with our old libxm interface was for for our particular product offering
we just didnt have the option to say "also supports most existing xm
configurations" [in terms of official marketing product support statements
it was 'better' to say we dont support any...]. If you are OK with
recommending to users to use libvirt-based tools to create DomUs, but that
most other typical xm config files are supported too (if you put them in
such and such place) then I dont see a problem.

At the *very* worst, is there a way you can pipe an arbitrary xm config
file thru xm and have it spit out what it would have done, without actually
doing it? That could be a reliable fallback migration path perhaps.

- Gareth

Dr. Gareth S. Bestor
IBM Linux Technology Center
M/S DES2-01
15300 SW Koll Parkway, Beaverton, OR 97006
503-578-3186, T/L 775-3186, Fax 503-578-3186

             "Daniel P.                                                    
             Berrange"                                                     
             <berrange at redhat.                                          To 
             com>                      Daniel Veillard                     
             Sent by:                  <veillard at redhat.com>               
             libvir-list-bounc                                          cc 
             es at redhat.com             libvir-list at redhat.com              
                                                                   Subject 
                                       Re: [Libvir] Semantics for          
             08/23/06 05:23 PM         ListDomains/ ListDefinedDomains     

             Please respond to                                             
                "Daniel P.                                                 
                 Berrange"                                                 
             <berrange at redhat.                                             
                   com>                                                    

On Wed, Aug 23, 2006 at 05:15:26PM -0400, Daniel Veillard wrote:
> On Wed, Aug 23, 2006 at 09:22:08PM +0100, Daniel P. Berrange wrote:
> > 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.

Well there's unlikely to be random apps writing into /etc/xen unless
they're related to Xen config. We can ust blacklisted the 'xend-config.sxp'
file (& perhaps the xmexample* files)

> >  * 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.

Sounds good.

> > 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 ?

Sounds like we should, unless anyone (CIM guys ?) listening in has better
suggestions ?

Regards,
Dan.
--
|=- 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
-=|

--
Libvir-list mailing list
Libvir-list at redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20060823/23b35b2c/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20060823/23b35b2c/attachment-0003.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic07763.gif
Type: image/gif
Size: 1255 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20060823/23b35b2c/attachment-0004.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20060823/23b35b2c/attachment-0005.gif>