Re: RFC: get/set properties

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]