On Fri, Apr 27, 2007 at 10:32:33PM +0900, Saori Fukuta wrote:
> Hi Daniel
Hi Saori,
> I'm sorry I might be disrespectful a little...
No, you were not. I'm just stating I'm thinking of the problem in different
terms, which I think are open to discussion.
> I understood descriptions of domains, and I will think over again with members
> of my team.
>
> I appreciate your explaining.
>
> thanks a lot !
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@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/