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

[Saori Fukuta]

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 */
};

>   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.

>   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.

Thanks,
Saori Fukuta