[libvirt] New Libvirt Implementation - OpenNebula

[Daniel P. Berrange]

On Mon, Nov 03, 2008 at 08:32:54PM +0100, Ruben S. Montero wrote:
> On Monday 03 November 2008 17:59:33 Daniel Veillard wrote:
> >
> >   This is a bit against the Node principle of libvirt, and could result
> > in some fun in the hardware discovery mode, but in general the approach
> > might work. Still we are looking at bits on the node to provide
> > capabilities of the hypervisor, which may break in your case, and
> > migration is defined as an operation between a domain in a given node
> > and a connection to another node, so the migration within the OpenNebula
> > cluster won't be expressable in a simple way with the normal libvirt
> > API. Except that things should work conceptually I think.
> 
> You are totally right, this is putting the standard to the limit ;). There are 
> some function calls that can not be implemented right away or, as you said, 
> the semantics are slightly different. Maybe there is room to extend the API in 
> the future, right now there is no standard way to interface a distributed VM 
> Manager....

This is a really interesting problem to figure out. We might like to
extend the node capabilities XML to provide information about the
cluster as a whole - we currently have  <guest> element describing
what guest virt types are supported by a HV connection, and a <host>
element describing a little about the host running the HV. It might
make sense to say that the <host> info is optional and in its place
provide some kind of 'cluster' / 'host group' information. I won't
try to suggest what now - we'll likely learn about what would be
useful through real world use of your initial driver functionality.


> > Basically the contributtion should be provided as a (set of) patch(es)
> > agaisnt libvirt CVS head. Preferably the code should follow the existing
> > coding guidelines of libvirt, reuse the existing infrastructure for
> > error, memory allocations, etc ... If "make check syntax-check' compiles
> > cleanly with your code applied that's a good first start :-)
> > In general the inclusion takes a few iteration of reviews before being
> > pushed, and splitting patches into smaller chunks helps the review
> > process greatly.
> > I didn't yet took the time to look at the patch online, so I have no
> > idea a-priori of the work needed. Drivers are usually clean and
> > separate, the problem is have them in the code base to minimize
> > maintainance.
> >
> 
> Ok. It sounds fine. We will update our implementation to CVS head (right now 
> the patch is targeted for 0.4.4), update licenses to LGPL, and we will check 
> if 'make check syntax-check' works. Also We'll try to split the patch in self-
> contained changes, so they are easy to review. I'll let you know when we are 
> done...

When you update to work with latest CVS, I'd strongly recommend you make
use of the  brand new XML handling APIs we have in domain_conf.h. We have
switched all drivers over to use these shared internal APIs for parsing
the domain XML schema, so it would let you delete 90% of your one_conf.c
file.

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