
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:
On Wed, Aug 23, 2006 at 02:21:03PM -0400, Daniel Veillard wrote:
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 [...] * 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 :-) [...]
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 ?
Okay, there is a a first version in CVS under libvirt/src/conf.[ch] It allows only variable assignments and comments, the types supported are the [] lists, integers and strings. Still that should be sufficient to handled most data oriented existing Python Xen configurations. It supports load/lookup/writes as defined in conf.h: ------------------------------------- typedef struct _virConf virConf; typedef virConf *virConfPtr; virConfPtr virConfReadFile (const char *filename); virConfPtr virConfReadMem (const char *memory, int len); int virConfFree (virConfPtr conf); virConfValuePtr virConfGetValue (virConfPtr conf, const char *setting); int virConfWriteFile (const char *filename, virConfPtr conf); int virConfWriteMem (char *memory, int *len, virConfPtr conf); ------------------------------------- Values are open structures: ------------------------------------- /** * virConfType: * one of the possible type for a value from the configuration file * * TODO: we probably need a float too. */ typedef enum { VIR_CONF_NONE = 0, /* undefined */ VIR_CONF_LONG = 1, /* a long int */ VIR_CONF_STRING = 2, /* a string */ VIR_CONF_LIST = 3 /* a list */ } virConfType; /** * virConfValue: * a value from the configuration file */ typedef struct _virConfValue virConfValue; typedef virConfValue *virConfValuePtr; struct _virConfValue { virConfType type; /* the virConfType */ virConfValuePtr next; /* next element if in a list */ long l; /* long integer */ char *str; /* pointer to 0 terminated string */ virConfValuePtr list; /* list of a list */ }; ------------------------------------- If needed it's possible to lookup a value, change the object and save back, I could extend the supported subset to handle expressions or reuse of variables in assignments, but I'm not sure it is really worth it. The parser is strict, if it meets a construct it doesn't recognize it fails and return NULL with an error. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/