[libvirt] New Libvirt Implementation - OpenNebula
Dear all, You may find of interest a new implementation of the libvirt virtualization API. This new implementation adds support to OpenNebula, a distributed VM manager system. The implementation of libvirt on top of a distributed VM manager, like OpenNebula, provides an abstraction of a whole cluster of resources (each one with its hypervisor). In this way, you can use any libvirt tool (e.g. virsh, virt-manager) and XML domain descriptions at a distributed level. For example, you may create a new domain with 'virsh create', then OpenNebula will look for a suitable resource, transfer the VM images and boot your VM using any of the supported hypervisors. The distributed management is completely transparent to the libvirt application. This is, a whole cluster can be managed as any other libvirt node. The current implementation is targeted for libvirt 0.4.4, and includes a patch to the libvirt source tree (mainly to modify the autotools files), and a libvirt driver. More information and download instructions can be found at: * http://trac.opennebula.org/wiki/LibvirtOpenNebula * http://www.opennebula.org Cheers Ruben -- +---------------------------------------------------------------+ 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 +---------------------------------------------------------------+
On Mon, Nov 03, 2008 at 12:23:47PM +0100, Ruben S. Montero wrote:
Dear all, You may find of interest a new implementation of the libvirt virtualization API. This new implementation adds support to OpenNebula, a distributed VM manager system. The implementation of libvirt on top of a distributed VM manager, like OpenNebula, provides an abstraction of a whole cluster of resources (each one with its hypervisor). In this way, you can use any libvirt tool (e.g. virsh, virt-manager) and XML domain descriptions at a distributed level.
For example, you may create a new domain with 'virsh create', then OpenNebula will look for a suitable resource, transfer the VM images and boot your VM using any of the supported hypervisors. The distributed management is completely transparent to the libvirt application. This is, a whole cluster can be managed as any other libvirt node.
The current implementation is targeted for libvirt 0.4.4, and includes a patch to the libvirt source tree (mainly to modify the autotools files), and a libvirt driver.
More information and download instructions can be found at:
* http://trac.opennebula.org/wiki/LibvirtOpenNebula * http://www.opennebula.org
Interesting, but this raises a couple of questions: - isn't OpenNebula in some way also an abstraction layer for the hypervisors, so in a sense a libvirt driver for OpenNebula is a bit 'redundant' ? Maybe i didn't understood well the principles behind OpenNebula :-) (sorry first time I learn about this). - what is the future of that patch ? Basically libvirt internals changes extremely fast, so unless a driver gets included as part of libvirt own code source, there is a lot of maintainance and usability problems resulting from the split. Do you intent to submit it for inclusion, or is that more a trial to gauge interest ? Submitting the driver for inclusion means the code will have to be reviewed, released under LGPL, and a voluteer should be available for future maintainance and integration issues. thanks ! Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
Hi Daniel On Monday 03 November 2008 16:43:32 Daniel Veillard wrote:
Interesting, but this raises a couple of questions: - isn't OpenNebula in some way also an abstraction layer for the hypervisors, so in a sense a libvirt driver for OpenNebula is a bit 'redundant' ? Maybe i didn't understood well the principles behind OpenNebula :-) (sorry first time I learn about this).
Yes you are right, OpenNebula provides an abstraction layer for A SET of distributed resources (like Platform VM Orchestrator or VMWare DRS). In this way, OpenNebula leverages the functionality provided by the underlying VM hypervisors to provide a centralized management (allocation and re/allocation of VMs, balance of workload....) of a pool physical resources. The libvirt API is just another interface to the OpenNebula system. The beauty is that you can manage a whole cluster of hypervisors using the libvirt standard, i.e. in the same way you interact with a single machine. For example, oVirt uses libvirt to interact with the physical nodes. With OpenNebula+libvirt, one of the nodes managed with oVirt could be a whole cluster. In this case you could use the great interface from oVirt to manage several clusters. And you could abstract those applications from the details of managing the cluster (for example, is there NFS in it?, group/user policies...) Finally, and may be adding more confusion, OpenNebula also uses libvirt underneath to interface with some of the hypervisors of the physical nodes (e.g. KVM).
- what is the future of that patch ? Basically libvirt internals changes extremely fast, so unless a driver gets included as part of libvirt own code source, there is a lot of maintainance and usability problems resulting from the split. Do you intent to submit it for inclusion, or is that more a trial to gauge interest ? Submitting the driver for inclusion means the code will have to be reviewed, released under LGPL, and a voluteer should be available for future maintainance and integration issues.
Yes we are highly interested in contributing the driver. We have no problems with the requirements and we can commit resources to maintain and integrate the driver. Please let me know how we should proceed...
thanks !
Daniel
Cheers Ruben -- +---------------------------------------------------------------+ 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 +---------------------------------------------------------------+
On Mon, Nov 03, 2008 at 05:26:34PM +0100, Ruben S. Montero wrote:
Hi Daniel On Monday 03 November 2008 16:43:32 Daniel Veillard wrote:
Interesting, but this raises a couple of questions: - isn't OpenNebula in some way also an abstraction layer for the hypervisors, so in a sense a libvirt driver for OpenNebula is a bit 'redundant' ? Maybe i didn't understood well the principles behind OpenNebula :-) (sorry first time I learn about this).
Yes you are right, OpenNebula provides an abstraction layer for A SET of distributed resources (like Platform VM Orchestrator or VMWare DRS). In this way, OpenNebula leverages the functionality provided by the underlying VM hypervisors to provide a centralized management (allocation and re/allocation of VMs, balance of workload....) of a pool physical resources.
The libvirt API is just another interface to the OpenNebula system. The beauty is that you can manage a whole cluster of hypervisors using the libvirt standard, i.e. in the same way you interact with a single machine.
After further reading, yes I understand, it's the reverse appraoch from ovirt, where we use libvirt to build the distributed management. One interesting point is that your driver would allow to access EC2 using libvirt APIS...
For example, oVirt uses libvirt to interact with the physical nodes. With OpenNebula+libvirt, one of the nodes managed with oVirt could be a whole cluster. In this case you could use the great interface from oVirt to manage several clusters. And you could abstract those applications from the details of managing the cluster (for example, is there NFS in it?, group/user policies...)
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.
Finally, and may be adding more confusion, OpenNebula also uses libvirt underneath to interface with some of the hypervisors of the physical nodes (e.g. KVM).
Ouch :-) okay !
- what is the future of that patch ? Basically libvirt internals changes extremely fast, so unless a driver gets included as part of libvirt own code source, there is a lot of maintainance and usability problems resulting from the split. Do you intent to submit it for inclusion, or is that more a trial to gauge interest ? Submitting the driver for inclusion means the code will have to be reviewed, released under LGPL, and a voluteer should be available for future maintainance and integration issues.
Yes we are highly interested in contributing the driver. We have no problems with the requirements and we can commit resources to maintain and integrate the driver. Please let me know how we should proceed...
Well well well ... 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. Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
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....
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... Cheers Ruben -- +---------------------------------------------------------------+ 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 +---------------------------------------------------------------+
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 :|
Daniel P. Berrange wrote:
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.
It is great(!) to see that someone actually started to care about this; but honestly requests for these things were before blundly rejected. See: Comfortable lookup functions interface/block stats Could someone elaborate why after 5 months I can tag this project as 'suddenbreakoutofcommonsense'? Stefan
On Tue, Nov 04, 2008 at 12:39:11AM +0100, Stefan de Konink wrote:
Daniel P. Berrange wrote:
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.
It is great(!) to see that someone actually started to care about this; but honestly requests for these things were before blundly rejected.
If you look at the mailing list archives you'll find this generic domain XML api was a long standing item on our TODO list. We had been planning to implenent & working towards it over time.
Could someone elaborate why after 5 months I can tag this project as 'suddenbreakoutofcommonsense'?
If you want to be a troll please go elsewhere. 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 :|
Last time *your* argument was that the API would get too big. Now why isn't that argument valid anymore? I'm honestly asking for an explanation on this point, and I do expect you have it. Stefan
On Tue, Nov 04, 2008 at 05:04:50PM +0100, Stefan de Konink wrote:
Last time *your* argument was that the API would get too big. Now why isn't that argument valid anymore? I'm honestly asking for an explanation on this point, and I do expect you have it.
You are confusing internal API with external API. The external API has scalability issues because it is a long term supported ABI. The internal API size is irrelevant because we can & will change that at will. The domain XML handling API is internal only for in-tree drivers. So there has been no change in policy wrt to the external API 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 :|
Daniel P. Berrange wrote:
On Tue, Nov 04, 2008 at 05:04:50PM +0100, Stefan de Konink wrote:
Last time *your* argument was that the API would get too big. Now why isn't that argument valid anymore? I'm honestly asking for an explanation on this point, and I do expect you have it.
You are confusing internal API with external API. The external API has scalability issues because it is a long term supported ABI. The internal API size is irrelevant because we can & will change that at will. The domain XML handling API is internal only for in-tree drivers. So there has been no change in policy wrt to the external API
Is an external tool able to use the internal XML handling (from a C perspective?) or isn't this code exported to the shared library? Stefan ps. Sorry if you thought I was trying to virtualize a troll.
As part of the internal API (and not explicitly exported from src/libvirt_sym.version) The xml parsing would not be available to external apps. Stefan de Konink wrote on 11/04/2008 11:21 AM:
Daniel P. Berrange wrote:
On Tue, Nov 04, 2008 at 05:04:50PM +0100, Stefan de Konink wrote:
Last time *your* argument was that the API would get too big. Now why isn't that argument valid anymore? I'm honestly asking for an explanation on this point, and I do expect you have it.
You are confusing internal API with external API. The external API has scalability issues because it is a long term supported ABI. The internal API size is irrelevant because we can & will change that at will. The domain XML handling API is internal only for in-tree drivers. So there has been no change in policy wrt to the external API
Is an external tool able to use the internal XML handling (from a C perspective?) or isn't this code exported to the shared library?
Stefan
ps. Sorry if you thought I was trying to virtualize a troll.
-- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Tue, Nov 04, 2008 at 05:21:50PM +0100, Stefan de Konink wrote:
Daniel P. Berrange wrote:
On Tue, Nov 04, 2008 at 05:04:50PM +0100, Stefan de Konink wrote:
Last time *your* argument was that the API would get too big. Now why isn't that argument valid anymore? I'm honestly asking for an explanation on this point, and I do expect you have it.
You are confusing internal API with external API. The external API has scalability issues because it is a long term supported ABI. The internal API size is irrelevant because we can & will change that at will. The domain XML handling API is internal only for in-tree drivers. So there has been no change in policy wrt to the external API
Is an external tool able to use the internal XML handling (from a C perspective?) or isn't this code exported to the shared library?
No, the internal APIs are only intended for use by code that is part of libvirt source tree. While some of the internal APIs may appear in the shared library, they are strictly for private use by the libvirtd daemon because we can make no guarentee that they will work across even bug-fix releases of libvirt. We are working on enforcing the privacy of internal APIs using better linker scripts to control symbol visibility. 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 :|
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 +---------------------------------------------------------------+
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....
As Dan expressed too, that's not a blocker, we can find ways to increase the APIs or the expressiveness of the XML descriptions used. But it's not urgent, the basic operations can be implemented without this.
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...
Cool. In a sense there is no real hurry, I would like to make the 0.5.0 release probably end of next week, and we have much to review and check before that, if your patches could arrive shortly after the 0.5.0 release that would be a nice time to integrate them. Of course earlier patch are not a problem but we will probably have less time to review them considering the things started but not finished for 0.5.0 :-) thanks ! Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
On Tuesday 04 November 2008 09:12:00 Daniel Veillard wrote:
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...
Cool. In a sense there is no real hurry, I would like to make the 0.5.0 release probably end of next week, and we have much to review and check before that, if your patches could arrive shortly after the 0.5.0 release that would be a nice time to integrate them. Of course earlier patch are not a problem but we will probably have less time to review them considering the things started but not finished for 0.5.0 :-)
thanks !
Daniel
Great, It make sense we'll target the new version of our driver for the 0.5.0 version. Good luck with 0.5.0!! Cheers Ruben -- +---------------------------------------------------------------+ 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 +---------------------------------------------------------------+
participants (5)
-
Ben Guthro -
Daniel P. Berrange -
Daniel Veillard -
Ruben S. Montero -
Stefan de Konink