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=' attribute. 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 > >applied > >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. Dan. -- |: 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 :| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list