Re: [Libvir] [RFC] Life-cycle Management of the domain take2

On Fri, Apr 27, 2007 at 10:32:33PM +0900, Saori Fukuta wrote: Hi Saori, No, you were not. I'm just stating I'm thinking of the problem in different terms, which I think are open to discussion. To me changing the memory allocation of a live domain and the value in configuration file are not the same kind of operation, they are similar but trying to keep identical APIs based on virDomainPtr becomes confusing. Sometime you want to change a running domain, somethimes you want to change the config file, sometimes both. By mixing the whole in a single entry point assume you can actually identify both kind of objects (i.e. the domain and the config file it came from). I do not think it is possible: - the domain may not be running - the config file may not be available - the domain may already have diverged from the config file Keeping a coherent view and clean handling of errors looks nearly impossible. 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 proposal 2: Or we could keep with the idea that a virDomain could represent a config file as for Xen unactive guests, but then a virDomain could only represent one or the other but not both. Which mean if you wanted to modify both the config file and the running domain you would need 2 different virDomain objects (and then you would still be using virDomainSetMemory() but calling it twice). 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. The main drawback of proposal 2 is that it mixes 2 kind of objects with different capabilities (configuration and running domains), but would keep the API smaller. I certainly need to think more about this :-) Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/