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

[Daniel Veillard]

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 at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/