[libvirt] New Libvirt Implementation - OpenNebula

Ruben S. Montero rubensm at dacya.ucm.es
Mon Nov 3 16:26:34 UTC 2008

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. 

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 

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). 

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

>   thanks !
> 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

More information about the libvir-list mailing list