Re: [Libvir] RFC: get/set properties
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(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/