[libvirt] New Libvirt Implementation - OpenNebula

Tue Nov 4 23:44:07 UTC 2008

Hi Daniel,
Thanks very much for your suggestions, the new version of the driver will make 
use of the new XML handing API. Regarding the use of a 'cluster' or 'host 
group' element  we'll make a summary of the limitations we found when dealing 
with a cluster, so you can have a clear view.

Cheers

Ruben

On Tuesday 04 November 2008 00:29:09 Daniel P. Berrange wrote:
> 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

-- 
+---------------------------------------------------------------+
 Dr. Ruben Santiago Montero
 Associate Professor
 Distributed System Architecture Group (http://dsa-research.org)

 URL:    http://dsa-research.org/doku.php?id=people:ruben
 Weblog: http://blog.dsa-research.org/?author=7

 GridWay, http://www.gridway.org
 OpenNEbula, http://www.opennebula.org
+---------------------------------------------------------------+