[Libvir] RFC: get/set properties

[Ryan Scott]

Daniel P. Berrange wrote:
> On Tue, Apr 15, 2008 at 11:31:32AM -0700, Ryan Scott wrote:
>>   I'd like to get some comments on the following...
>>
>>   We would like to use libvirt to store some properties related to a 
>> domain.  This can be done by adding a simple get/set API as follows:
> 
> What are the properties ?  I'm not really very enthusiastic about the
> idea of adding API / XML for generic key,value properties. I think it
> will quickly be abused as a way to add arbitrary, non-standardized 
> hypervisor / driver specific configuration which would be better 
> represented with explicit schema.

One thing we have in mind is driver/software version numbers.  For 
example, the control tools may change the domain configuration based on 
whether a certain driver has the support for a new feature.  If we 
create the domain's xml with the driver information, we can make this 
decision quickly, on the fly, in dom0.

While this information is related to domain configuration, it's not 
hypervisor-specific, so I'm not sure where else we would put it in the 
domain's XML description.

This gives the control tools someplace to store that information, rather 
than having to create some separate storage for each domain.

> 
>> /*
>>  * Domain property get/set interfaces
>>  *
>>  * For GetProp, the return value must be freed by the caller.
>>  */
>> char *          virDomainGetProp    (virDomainPtr domain,
>>                         const char *propName);
>>
>> int         virDomainSetProp    (virDomainPtr domain,
>>                         const char *propName,
>>                         const char *value);
> 
>>   The XML would look something like this:
>>
>> virsh # dumpxml solaris-pv-0
>> <domain type='xen' id='-1'>
>> [ snip ]
>>   <properties>
>>     <blah value="3"/>
>>     <foo value="bar"/>
>>   </properties>
>> </domain>
> 
> One of the key ideas behind libvirt is that we try to provide a consistent
> set of configuration options across all drivers. NB, I'm not saying we need
> the lowest-common denominator - just that we try to formalize a way to
> represent every configuration option in such a away that it could be applied
> to any driver.  I don't think simple  key,value pairs are sufficient in the
> general case. 

This wasn't meant to be a generic solution to handle storage of all 
domain information.  For your example below, if someone wants more 
information on the console, the API should be extended to allow that.

However, extending the API to every piece of information for a domain 
seems to be overkill.  That's why we just want a simple name/value pair.

-Ryan

> 
> As an example, you could define a property 'console' which takes a pty path
> as its value. But  if you want to generalize this to different types of
> console access, then a single value becomes insufficient.eg need a host+port
> for a console accessed over TCP. The more explicit specialized <console>
> tag allows us the flexibility of adding attributes and sub-elements as 
> needed, not restricting ourselves to key,value pairs.
> 
> Dan,