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 :| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list