Re: [libvirt] [RFC] Unify KVM kernel-space and user-space code into a single project

On Fri, Apr 09, 2010 at 09:49:51AM +0200, Daniel Veillard wrote: > On Thu, Apr 08, 2010 at 11:27:46PM +0100, Antoine Martin wrote: > > Hi, > > > > I am moving this thread here as this seems more appropriate. > > Sorry it has taken so long.. > > > > Here are 2 things that really get in the way of moving my existing > > installations to libvirt: > > * I tend to store much meta data with each VM instance: it can be things > > like ownership (contact details as text), monitoring info (sms phone > > numbers), backup (list of paths), firewall rules (custom syntax, with > > failover rules, etc), etc. > > At the moment, these extra bits of information consist of just a few > > optional lines of shell in each VM's definition file. I can extend these > > whenever I need, enumerate the VMs using the standard mechanism and > > trigger my specific actions as needed (firewall rules, backup or whatever). > > I see no way of doing this with libvirt. But please correct me if I am > > wrong. > > One of the things I'm gonna do post 0.8.0 is allow to bundle comments > and elements from a foreign namespace in the libvirt XML definition. > > Currently libvirt will happilly consume such a definition but all the > extra are lost, basically at parse time we just extract the informations > we know about, and everything else is lost. I want to provide clean ways > to add metadata coming from the user and preserve them. I will probably > limit the places where such metadata will be allowed: > > 1/ to avoid the full complexity of an XML structured editor within > libvirt > 2/ to not have to completely modify our configuration reading and > saving code, but add this as an extra layer > 3/ to be able to modify the Relax-NG schemas in a reasonnable way > to allow those elements from foreign namespaces > > It's not a piece of cake, there will have to be some limitation and > heuristics to avoid the extreme complexity and changes that a full tree > preservation system would requires, but I think that should be > sufficient for your kind of use case, Daniel, this kind of thing would allow (for example) the addition of information to the domain XML that could be used by an event hook script? I guess by the script getting the domain XML and fishing out the extra metadata bits?