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