[Libvir] RFC: get/set properties
Daniel P. Berrange
berrange at redhat.com
Wed Apr 16 13:45:29 UTC 2008
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.
What are the drivers for ? As an example, if you're refering to drivers
for the backend disk devices assigned to a guest, then we alreayd have
a <driver/> element for <disk> devices, where we can add a 'version='
If its not per-domain specific, then we have the 'capabilities' XML
format which can be used to expose information about the capabilities
of a hypervisor. For now we expose information about supported migration
protocols, supported OS types & architectures. There's clearly scope
for defining further bits of metadata here.
So unless more concrete examples of properties come to light I'm still
not seeing any compelling argument for generic key,value pairs.
> >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
> >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.
While extending the XML format for every piece of information is clearly
more work than a generic name/value pair, this is a worthwhile tradeoff
because it forces us to think about the scope of everything we add, and
hopefully come up with an optimal way of representing it.
|: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
More information about the libvir-list