Re: [libvirt] New Libvirt Implementation - OpenNebula
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(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/