Henri Cook wrote:
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.
The end users are free to do that, but this presents a simplified administration model. Why create a separate database, when the information we need can be stored in the domain description?
-Ryan
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@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
-- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list