On Tue, Jan 10, 2006 at 11:19:54AM -0600, Anthony Liguori wrote: > Howdy, > > Thought I'd try to start up a discussion on a topic that I know I've > discussed a lot with people in the past. > > Xend currently stores its configurations in python files somewhere on > the file system (usually in /etc/xen). This is problematic from a > management tool perspective because the python files may contain > arbitrary python code (requiring a python interpreter to read) and > there's no central location which makes enumerating possible domains > quite difficult. Yeah my first reaction was to provide XML based configuration files that libvir would be able to understand, but I really think the configurations may come from very varied sources possibly databases. That's why I would rather have the library agnostic when it comes to what a configuration may look like. > If you think about a typical use-case (or at least, my typical use-case > :-)), a user is likely to have a larger number of domains than what are > running (say a domain for a bunch of different distros for testing). It > would be nice if any management tools could see those domains and easily > start them up. What is needed to start a domain ? For Xen we know what is needed, at least at the moment (paths to kernels, images, block devices paths, network devices and I/Os), but this may change slightly with full virtualization, and other virtualization engine like QEmu have different ways since they emulate the bootstrap process too. To me we don't have a good answer to this question so that's one more reason to keep this as opaque as possible. > I think we could achieve this with the following requirements: > > 1) Allow domain creation based on an opaque configuration object > 2) Allow storing and retrieval of these configuration objects from the > XenStore (using a user-specified path) > > I think this isolates the state well enough that it leaves the majority > of the library stateless. Just some random thoughts... Hum ... you will still need to put some decoding of this object inside the library to pass enough information to xend to start it (since I believe that we will need to use the xend API to create domains). This doesn't make the code agnostic to the format but it makes the API agnostic which is important too (though the versionning as xen evolves sounds a bit hellish, we'd better carefully design the versioning in that format :-) Daniel -- Daniel Veillard | Red Hat http://redhat.com/ veillard@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/