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@redhat.com>
"Daniel P. Berrange" <berrange@redhat.com>
Sent by: libvir-list-bounces@redhat.com
08/23/06 05:23 PM
Please respond to
"Daniel P. Berrange" <berrange@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@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list