Hi Daniel, Thanks very much for your suggestions, the new version of the driver will make use of the new XML handing API. Regarding the use of a 'cluster' or 'host group' element we'll make a summary of the limitations we found when dealing with a cluster, so you can have a clear view. Cheers Ruben On Tuesday 04 November 2008 00:29:09 Daniel P. Berrange wrote: > 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 -- +---------------------------------------------------------------+ 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 +---------------------------------------------------------------+ -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list