[libvirt] New Libvirt Implementation - OpenNebula
Daniel P. Berrange
berrange at redhat.com
Mon Nov 3 23:29:09 UTC 2008
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 :|
More information about the libvir-list
mailing list