On Thu, May 10, 2007 at 12:06:51PM +0900, Saori Fukuta wrote: > Hi Daniel, > > Thank you for your proposal ! I considered the way with it. > > On Fri, 27 Apr 2007 10:35:15 -0400 Daniel Veillard wrote: > > So I have a problem with this, and I suggest to isolate configuration > > file APIs, which in practice would mean client code a bit more verbose > > but keeping the API simpler. > > We have a long week-end ahead, I will try to get back with more complete > > proposal, but I could see a set of API like: > > > > proposal 1: > > > > - create a config from a string (or file) > > we could autodetect the kind of configs here and automatically support > > XML, sexpr, old Xen config files, and also VMWare-like ones > > - create a config from a running domain (like virDomainGetXMLDesc does) > > - modify values from a config > > - get a value from a config > > - save a config (as libvirt XML) in a string or file > > > > The main drawback of proposal 1 is that it increase the API, but would make > > clear what kind of objects are been managed, i would also allow more specific > > configuration only option in the future. > > I think that the proposal is good to keep the API simple, though, the number > of API increases. Well I have though about it more, and I'm afraid that proposal 1 makes things more complex due to the duplication of APIs. I think proposal 2 makes more sense, i.e. be able to create a Domain object from a config file. We just need to add new API to generate an xmlDomainPtr from those data, then store the path or data in the domain structure, and also a new API to be able to differentiate whether a domain is about a running domain or just the config. > Here is an example of the interface. > > We could provide new API (like virDomainSetMemoryConfig), and use only it for > not running domain. The problem is that one need to add one such API for every aspect of the domain configuration, if it was only memory that would not be that bad but we ultimately want to be able to modify everything. > # virsh setmem foo 200 We need to be cautious the Xen model will not match other virtualization engines, for example if you run a KVM the system won't try to keep a database of settings. [...] > I think this is the better way than I suggested before. > How does this look ? Better but I'm not sure it's the right way. I am sorry but I am slow to get there I don't want to make the wrong choise. I think it's better to allow the duality of virDomainPtr, accepting it to be either a representation for a running domain or a representation of the associated configuration file. The fact that with new versions of Xen one can change into the other doesn't sound something that will be common to other engines, and as you noted it actually makes things harder because if you call the API you don't know a-priori without checking the current state which aspect will be modified. So we need to separate the two states, but if we can keep the same APIs for most of the modification entry points and just add a few call to create the configuration domains and being able to ask if a domain is about a config or about a running one. I welcome feedback from others, I think it is a rather complex issue and would feel better commiting to an API here if I could feel some consensus, Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/