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@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list