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

[Daniel Veillard]

On Fri, May 11, 2007 at 10:57:10PM +0900, Saori Fukuta wrote:
> On Thu, 10 May 2007 12:36:30 -0400 Daniel Veillard  wrote:
> >   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.
> 
> Can I ask something ? That means adding xmlDomainPtr to virDomainPtr,
> like this ?
> 
> struct _virDomain {
>     unsigned int magic;                  /* specific value to check */
>     int uses;                            /* reference count */
>     virConnectPtr conn;                  /* pointer back to the connection */
>     xmlDomainPtr conf; <----this one
>     char *name;                          /* the domain external name */
>     int id;                              /* the domain ID */
>     unsigned char uuid[VIR_UUID_BUFLEN]; /* the domain unique identifier */
> };

  I am not sure we can bind the two like this in general. That's something
which would be possible if you use a configuration and then ask to start
the domain (in a way similar to virDomainCreate() but from a configuration).
But we can't expect to have a configuration everytime we get a Domain.
If you start virsh and list the domains you will get the virDomainPtr
of running domains, but you won't be able to guess in general where the
config file for them would be. Does that make sense ?

> >   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.
> 
> Yes, I would like to modify another values, too.
> There are vcpus, disk, network interface, vncport...etc.

  Sounds normal.

> >   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. 
> 
> Now, the result of command seems not to be consistent when the domain is
> not running. So I think if we can separate the API between running
> domain and not running domain, we get the consistent result.

  I'm not sure I understand. Say you use virDomainSetMemory() with a 
very large value. I agree that if you target a running domain you may 
get an error due to lack of memory on the host, while running the 
same call on a virDomainPtr addressing a configuration file you are
not likely to see such error raised. Are you concerned by this kind of
difference in behaviour or something else ?

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/