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 :|