Re: [libvirt] New Libvirt Implementation - OpenNebula
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 :|