[Libvir] RFC: get/set properties

[Daniel Veillard]

On Tue, Apr 15, 2008 at 02:23:53PM -0700, Ryan Scott wrote:
> 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.

Taking the specific example of driver support I think it's far better to
express that as part of the device description of the domain.
If it's about the Guest OS currently we only have a generic
  <domain>
    <os>
      <type> ...</type>
having a version attribute there sounds reasonable.
If it's about the emulated hardware, for example the number of crypto
engine like in the lDOM description the proper place would under
  <domain>
    <features>

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

  Domain configuration pertains to the XML domain description for sure
but this need to be added in a structured way.

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

I think every new addition to the structure need to be examined on a case
by case basis, in order to keep libvirt API and the tools buit on top of
them coherent. It is certainly more complex than opening the gate to a 
completely unstructured mechanism but like any API design, it takes a bit
of time and efforts to find the proper syntactic constructs. The effort
pays off on the long term IMHO.

Daniel

-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/