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.

> /* > * Domain property get/set interfaces > * > * For GetProp, the return value must be freed by the caller. > */ > char * virDomainGetProp (virDomainPtr domain, > const char *propName); > > int virDomainSetProp (virDomainPtr domain, > const char *propName, > const char *value); > The XML would look something like this: > > virsh # dumpxml solaris-pv-0 > <domain type='xen' id='-1'> > [ snip ] > <properties> > <blah value="3"/> > <foo value="bar"/> > </properties> > </domain> 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.

As an example, you could define a property 'console' which takes a pty path as its value. But if you want to generalize this to different types of console access, then a single value becomes insufficient.eg need a host+port for a console accessed over TCP. The more explicit specialized <console> tag allows us the flexibility of adding attributes and sub-elements as needed, not restricting ourselves to key,value pairs. Dan,

> 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.

> 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.

> want to be able to associate textual descriptions of the asset, or > define ownership. All of these are higher-level values that don't > necessarily have any meaning to the v12n technology itself. More > crucially they can be specific to the management tool, and lack any > reasonable generalization. Of course there is a need higher in the stack to associate metadata with the domain instance, but the fact this can be put in the hypervisor is a Xen specific as far as I can tell, and I'm reluctant to put this

in the libvirt XML format, because this is not hypervisor domain data, and would break portability as far as I can tell.

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.

>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.

My first thought as a layman is that libvirt should only contain information related to the actual running of the virtual machine i.e. not things that might concern say, customer data (this may not be your use case). I would say that's up to the end user to manage with their own databases, cross referenced with a virtual machine name or similar unique identifier.

I'd be interested to hear what those who've actually contributed to the project think though! :p Henri 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: > > /* > * Domain property get/set interfaces > * > * For GetProp, the return value must be freed by the caller. > */ > char * virDomainGetProp (virDomainPtr domain, > const char *propName); > > int virDomainSetProp (virDomainPtr domain, > const char *propName, > const char *value); > > > Sample command-line usage: > > virsh # setprop solaris-pv-0 foo bar > > virsh # setprop solaris-pv-0 blah 3 > > virsh # getprop solaris-pv-0 foo > foo: bar > > The XML would look something like this: > > virsh # dumpxml solaris-pv-0 > <domain type='xen' id='-1'> > [ snip ] > <properties> > <blah value="3"/> > <foo value="bar"/> > </properties> > </domain> > > Looking at the Xen code, I'll need to do a bit of work on that API > before I can implement this. I don't know how well this will fit into > the other hypervisors that Libvirt supports, so I'll leave those > implementations up to someone else :) > > Any thoughts? > > -Ryan > > -- > Libvir-list mailing list > Libvir-list(a)redhat.com > https://www.redhat.com/mailman/listinfo/libvir-list