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