[libvirt] New Libvirt Implementation - OpenNebula

[Daniel Veillard]

On Mon, Nov 03, 2008 at 05:26:34PM +0100, Ruben S. Montero wrote:
> Hi Daniel
> On Monday 03 November 2008 16:43:32 Daniel Veillard wrote:
> 
> >
> >   Interesting, but this raises a couple of questions:
> >     - isn't OpenNebula in some way also an abstraction layer for the
> >       hypervisors, so in a sense a libvirt driver for OpenNebula
> >       is a bit 'redundant' ? Maybe i didn't understood well the
> >       principles behind OpenNebula :-) (sorry first time I learn about
> >       this).
> 
> Yes you are right, OpenNebula provides an abstraction layer for A SET of 
> distributed resources (like Platform VM Orchestrator or VMWare DRS). In this 
> way, OpenNebula leverages the functionality provided by the underlying VM 
> hypervisors to provide a centralized management (allocation and re/allocation 
> of VMs, balance of workload....) of a pool physical resources. 
> 
> The libvirt API is just another interface to the OpenNebula system. The beauty 
> is that you can manage a whole cluster of hypervisors using the libvirt 
> standard, i.e. in the same way you interact with a single machine. 

  After further reading, yes I understand, it's the reverse appraoch
from ovirt, where we use libvirt to build the distributed management.
One interesting point is that your driver would allow to access EC2
using libvirt APIS...

> For example, oVirt uses libvirt to interact with the physical nodes. With 
> OpenNebula+libvirt, one of the nodes managed with oVirt could be a whole 
> cluster. In this case you could use the great interface from oVirt to manage 
> several clusters. And you could abstract those applications from the details 
> of managing the cluster (for example, is there NFS in it?, group/user 
> policies...)

  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.

> Finally, and may be adding more confusion, OpenNebula also uses libvirt 
> underneath to interface with some of the hypervisors of the physical nodes 
> (e.g. KVM). 

  Ouch :-) okay !

> >     - what is the future of that patch ? Basically libvirt internals
> >       changes extremely fast, so unless a driver gets included as part
> >       of libvirt own code source, there is a lot of maintainance and
> >       usability problems resulting from the split. Do you intent to
> >       submit it for inclusion, or is that more a trial to gauge interest ?
> >       Submitting the driver for inclusion means the code will have to be
> >       reviewed, released under LGPL, and a voluteer should be available
> >       for future maintainance and integration issues.
> 
> 
> Yes we are highly interested in contributing the driver. We have no problems 
> with the requirements and we can commit resources to maintain and integrate 
> the driver. Please let me know how we should proceed...

  Well well well ...
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.

Daniel

-- 
Daniel Veillard      | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
daniel at veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/