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@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
