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

Daniel P. Berrange berrange at redhat.com
Fri Apr 9 15:13:13 UTC 2010


On Fri, Apr 09, 2010 at 10:12:57AM -0400, Hugh O. Brock wrote:
> 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?

The hook is given the full XML document associated with the guest. Thus if we
add support for parsing & preserving extra namespaced elements in the XML, 
this data would be available to the hooks. The key is that the data must
roundtrip XML -> parsed format -> XML. Currently you can pas extra data in,
but it just gets ignored, so not roundtripped

Daniel
-- 
|: Red Hat, Engineering, London    -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org        -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|




More information about the libvir-list mailing list