Re: [Libvir] [RFC] Life-cycle Management of the domain take2
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