[libvirt] [PATCH 1/2] (Updated & fixed) OpenNebula driver, libvirt-0.6.2

Hi all, Here is the One driver & patches for the current git's master commit "9e9527 - Remove stale QEMU pidfiles". [PATCH 1/2] Patch to be applied to libvirt-0.6.2 sources and building files. [PATCH 2/2] Driver source code. Thanks for all the comments about the patches. We waited for the libvirt's release to update the driver's structure to 0.6.2 and apply the improvements. Here is a short list of the main changes applied: - Included driver's files in a different directory "src/opennebula" - Added Capabilities "virCapabilitiesAddGuest" for "x86_64" and "i686" guests and used "one" as hypervisor at "virCapabilitiesAddGuestDomain". - Instead creating a temporal file to send the VM definition we have updated the API we were using to being able to do everything in memory, so making use of "virBuffer" to create the VM definition Template. - Added previously unsupported features to the ONE Template, other types of disks and graphics (vnc,sdl) settings. - Fixed up warnings at compilation and make 'syntax-check' test passed. thanks, Abel Miguez. [PATCH 1/2] diff --git a/configure.in b/configure.in index dcacc7f..ab14303 100644 --- a/configure.in +++ b/configure.in @@ -186,6 +186,8 @@ AC_ARG_WITH([vbox], [ --with-vbox add VirtualBox support (on)],[],[with_vbox=yes]) AC_ARG_WITH([lxc], [ --with-lxc add Linux Container support (on)],[],[with_lxc=yes]) +AC_ARG_WITH([one], +[ --with-one add ONE support (on)],[],[with_one=no]) AC_ARG_WITH([test], [ --with-test add test driver support (on)],[],[with_test=yes]) AC_ARG_WITH([remote], @@ -305,6 +307,11 @@ if test "$with_uml" = "yes" ; then fi AM_CONDITIONAL([WITH_UML], [test "$with_uml" = "yes"]) +if test "$with_one" = "yes" ; then + AC_DEFINE_UNQUOTED([WITH_ONE],1,[whether ONE driver is enabled]) +fi +AM_CONDITIONAL([WITH_ONE],[test "$with_one" = "yes"]) + if test "$with_test" = "yes" ; then AC_DEFINE_UNQUOTED([WITH_TEST], 1, [whether Test driver is enabled]) fi @@ -406,6 +413,15 @@ dnl check for kvm headers dnl AC_CHECK_HEADERS([linux/kvm.h]) +dnl OpenNebula driver Compilation setting +dnl + +if test "$with_one" = "yes" ; then + CFLAGS="$CFLAGS -I$ONE_LOCATION/include" + ONE_LIBS="-L/usr/local/lib -lxmlrpc_client++ -lxmlrpc -lxmlrpc_util -lxmlrpc_xmlparse -lxmlrpc_xmltok -lxmlrpc++ -lxmlrpc_client -L$ONE_LOCATION/lib -loneapi" + AC_SUBST([ONE_LIBS]) +fi + dnl Need to test if pkg-config exists PKG_PROG_PKG_CONFIG @@ -1372,6 +1388,7 @@ AC_MSG_NOTICE([ UML: $with_uml]) AC_MSG_NOTICE([ OpenVZ: $with_openvz]) AC_MSG_NOTICE([ VBox: $with_vbox]) AC_MSG_NOTICE([ LXC: $with_lxc]) +AC_MSG_NOTICE([ ONE: $with_one]) AC_MSG_NOTICE([ Test: $with_test]) AC_MSG_NOTICE([ Remote: $with_remote]) AC_MSG_NOTICE([ Network: $with_network]) diff --git a/include/libvirt/virterror.h b/include/libvirt/virterror.h index faf3f61..abe54b2 100644 --- a/include/libvirt/virterror.h +++ b/include/libvirt/virterror.h @@ -63,6 +63,7 @@ typedef enum { VIR_FROM_XEN_INOTIFY, /* Error from xen inotify layer */ VIR_FROM_SECURITY, /* Error from security framework */ VIR_FROM_VBOX, /* Error from VirtualBox driver */ + VIR_FROM_ONE, /* Error from ONE driver */ } virErrorDomain; diff --git a/qemud/Makefile.am b/qemud/Makefile.am index 924e8ad..9d7f61f 100644 --- a/qemud/Makefile.am +++ b/qemud/Makefile.am @@ -120,6 +120,10 @@ if WITH_UML libvirtd_LDADD += ../src/libvirt_driver_uml.la endif +if WITH_ONE + libvirtd_LDADD += ../src/libvirt_driver_one.la +endif + if WITH_STORAGE_DIR libvirtd_LDADD += ../src/libvirt_driver_storage.la endif diff --git a/qemud/qemud.c b/qemud/qemud.c index 829a4bc..a069f38 100644 --- a/qemud/qemud.c +++ b/qemud/qemud.c @@ -75,6 +75,9 @@ #ifdef WITH_UML #include "uml_driver.h" #endif +#ifdef WITH_ONE +#include "opennebula/one_driver.h" +#endif #ifdef WITH_NETWORK #include "network_driver.h" #endif @@ -841,6 +844,7 @@ static struct qemud_server *qemudInitialize(int sigread) { virDriverLoadModule("qemu"); virDriverLoadModule("lxc"); virDriverLoadModule("uml"); + virDriverLoadModule("one"); #else #ifdef WITH_NETWORK networkRegister(); @@ -861,6 +865,9 @@ static struct qemud_server *qemudInitialize(int sigread) { #ifdef WITH_UML umlRegister(); #endif +#ifdef WITH_ONE + oneRegister(); +#endif #endif virEventRegisterImpl(virEventAddHandleImpl, diff --git a/src/Makefile.am b/src/Makefile.am index fd692b4..17ae0e7 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -144,6 +144,12 @@ UML_DRIVER_SOURCES = \ uml_conf.c uml_conf.h \ uml_driver.c uml_driver.h +ONE_DRIVER_SOURCES = \ + ./opennebula/one_conf.c \ + ./opennebula/one_conf.h \ + ./opennebula/one_driver.c \ + ./opennebula/one_driver.h + NETWORK_DRIVER_SOURCES = \ network_driver.h network_driver.c @@ -337,6 +342,25 @@ endif libvirt_driver_uml_la_SOURCES = $(UML_DRIVER_SOURCES) endif +if WITH_ONE +if WITH_DRIVER_MODULES +mod_LTLIBRARIES += libvirt_driver_one.la +else +noinst_LTLIBRARIES += libvirt_driver_one.la +# Stateful, so linked to daemon instead +#libvirt_la_LIBADD += libvirt_driver_one.la +endif +libvirt_driver_one_la_LDFLAGS = $(ONE_LIBS) + +if WITH_DRIVER_MODULES +libvirt_driver_one_la_LDFLAGS += -module -avoid-version +endif +libvirt_driver_one_la_SOURCES = $(ONE_DRIVER_SOURCES) +endif + + + + if WITH_NETWORK if WITH_DRIVER_MODULES mod_LTLIBRARIES += libvirt_driver_network.la @@ -429,6 +453,7 @@ EXTRA_DIST += \ $(QEMU_DRIVER_SOURCES) \ $(LXC_DRIVER_SOURCES) \ $(UML_DRIVER_SOURCES) \ + $(ONE_DRIVER_SOURCES) \ $(OPENVZ_DRIVER_SOURCES) \ $(VBOX_DRIVER_SOURCES) \ $(NETWORK_DRIVER_SOURCES) \ diff --git a/src/domain_conf.c b/src/domain_conf.c index 648d9e9..06b9713 100644 --- a/src/domain_conf.c +++ b/src/domain_conf.c @@ -55,7 +55,8 @@ VIR_ENUM_IMPL(virDomainVirt, VIR_DOMAIN_VIRT_LAST, "test", "vmware", "hyperv", - "vbox") + "vbox", + "one") VIR_ENUM_IMPL(virDomainBoot, VIR_DOMAIN_BOOT_LAST, "fd", diff --git a/src/domain_conf.h b/src/domain_conf.h index f4eea6b..c91a245 100644 --- a/src/domain_conf.h +++ b/src/domain_conf.h @@ -49,6 +49,7 @@ enum virDomainVirtType { VIR_DOMAIN_VIRT_VMWARE, VIR_DOMAIN_VIRT_HYPERV, VIR_DOMAIN_VIRT_VBOX, + VIR_DOMAIN_VIRT_ONE, VIR_DOMAIN_VIRT_LAST, }; diff --git a/src/driver.h b/src/driver.h index 39dc413..5685783 100644 --- a/src/driver.h +++ b/src/driver.h @@ -21,6 +21,7 @@ typedef enum { VIR_DRV_LXC = 6, VIR_DRV_UML = 7, VIR_DRV_VBOX = 8, + VIR_DRV_ONE = 9, } virDrvNo; diff --git a/src/libvirt.c b/src/libvirt.c index 95a861e..4b1610a 100644 --- a/src/libvirt.c +++ b/src/libvirt.c @@ -845,6 +845,10 @@ virGetVersion(unsigned long *libVer, const char *type, if (STRCASEEQ(type, "UML")) *typeVer = LIBVIR_VERSION_NUMBER; #endif +#if WITH_ONE + if (STRCASEEQ(type, "ONE")) + *typeVer = LIBVIR_VERSION_NUMBER; +#endif #if WITH_REMOTE if (STRCASEEQ(type, "Remote")) *typeVer = remoteVersion(); diff --git a/src/virterror.c b/src/virterror.c index 2d34ed7..d4b429c 100644 --- a/src/virterror.c +++ b/src/virterror.c @@ -156,6 +156,8 @@ static const char *virErrorDomainName(virErrorDomain domain) { break; case VIR_FROM_VBOX: dom = "VBOX "; + case VIR_FROM_ONE: + dom = "ONE "; break; } return(dom); ---- Distributed System Architecture Group (http://dsa-research.org) GridWay, http://www.gridway.org OpenNEbula, http://www.opennebula.org

Hi Abel
- Included driver's files in a different directory "src/opennebula"
Great, wouldn't crowd the src/ directory anymore, thanks.
domain) { break; case VIR_FROM_VBOX: dom = "VBOX "; + case VIR_FROM_ONE: + dom = "ONE "; break; } return(dom);
there is break missing here. will cause subtle errors if not failures. Regards, Pritesh

domain) { break; case VIR_FROM_VBOX: dom = "VBOX "; + case VIR_FROM_ONE: + dom = "ONE "; break; } return(dom);
there is break missing here. will cause subtle errors if not failures.
You are right, a mistake when resolving conflicts. I checked for more mistakes that could be produced at "rebase to master" and I think everything is right. By the way, this time the patch is attached. thanks, [PATCH 1/2] diff --git a/configure.in b/configure.in index dcacc7f..ab14303 100644 --- a/configure.in +++ b/configure.in @@ -186,6 +186,8 @@ AC_ARG_WITH([vbox], [ --with-vbox add VirtualBox support (on)],[],[with_vbox=yes]) AC_ARG_WITH([lxc], [ --with-lxc add Linux Container support (on)],[],[with_lxc=yes]) +AC_ARG_WITH([one], +[ --with-one add ONE support (on)],[],[with_one=no]) AC_ARG_WITH([test], [ --with-test add test driver support (on)],[],[with_test=yes]) AC_ARG_WITH([remote], @@ -305,6 +307,11 @@ if test "$with_uml" = "yes" ; then fi AM_CONDITIONAL([WITH_UML], [test "$with_uml" = "yes"]) +if test "$with_one" = "yes" ; then + AC_DEFINE_UNQUOTED([WITH_ONE],1,[whether ONE driver is enabled]) +fi +AM_CONDITIONAL([WITH_ONE],[test "$with_one" = "yes"]) + if test "$with_test" = "yes" ; then AC_DEFINE_UNQUOTED([WITH_TEST], 1, [whether Test driver is enabled]) fi @@ -406,6 +413,15 @@ dnl check for kvm headers dnl AC_CHECK_HEADERS([linux/kvm.h]) +dnl OpenNebula driver Compilation setting +dnl + +if test "$with_one" = "yes" ; then + CFLAGS="$CFLAGS -I$ONE_LOCATION/include" + ONE_LIBS="-L/usr/local/lib -lxmlrpc_client++ -lxmlrpc -lxmlrpc_util -lxmlrpc_xmlparse -lxmlrpc_xmltok -lxmlrpc++ -lxmlrpc_client -L$ONE_LOCATION/lib -loneapi" + AC_SUBST([ONE_LIBS]) +fi + dnl Need to test if pkg-config exists PKG_PROG_PKG_CONFIG @@ -1372,6 +1388,7 @@ AC_MSG_NOTICE([ UML: $with_uml]) AC_MSG_NOTICE([ OpenVZ: $with_openvz]) AC_MSG_NOTICE([ VBox: $with_vbox]) AC_MSG_NOTICE([ LXC: $with_lxc]) +AC_MSG_NOTICE([ ONE: $with_one]) AC_MSG_NOTICE([ Test: $with_test]) AC_MSG_NOTICE([ Remote: $with_remote]) AC_MSG_NOTICE([ Network: $with_network]) diff --git a/include/libvirt/virterror.h b/include/libvirt/virterror.h index faf3f61..abe54b2 100644 --- a/include/libvirt/virterror.h +++ b/include/libvirt/virterror.h @@ -63,6 +63,7 @@ typedef enum { VIR_FROM_XEN_INOTIFY, /* Error from xen inotify layer */ VIR_FROM_SECURITY, /* Error from security framework */ VIR_FROM_VBOX, /* Error from VirtualBox driver */ + VIR_FROM_ONE, /* Error from ONE driver */ } virErrorDomain; diff --git a/qemud/Makefile.am b/qemud/Makefile.am index 924e8ad..9d7f61f 100644 --- a/qemud/Makefile.am +++ b/qemud/Makefile.am @@ -120,6 +120,10 @@ if WITH_UML libvirtd_LDADD += ../src/libvirt_driver_uml.la endif +if WITH_ONE + libvirtd_LDADD += ../src/libvirt_driver_one.la +endif + if WITH_STORAGE_DIR libvirtd_LDADD += ../src/libvirt_driver_storage.la endif diff --git a/qemud/qemud.c b/qemud/qemud.c index 829a4bc..a069f38 100644 --- a/qemud/qemud.c +++ b/qemud/qemud.c @@ -75,6 +75,9 @@ #ifdef WITH_UML #include "uml_driver.h" #endif +#ifdef WITH_ONE +#include "opennebula/one_driver.h" +#endif #ifdef WITH_NETWORK #include "network_driver.h" #endif @@ -841,6 +844,7 @@ static struct qemud_server *qemudInitialize(int sigread) { virDriverLoadModule("qemu"); virDriverLoadModule("lxc"); virDriverLoadModule("uml"); + virDriverLoadModule("one"); #else #ifdef WITH_NETWORK networkRegister(); @@ -861,6 +865,9 @@ static struct qemud_server *qemudInitialize(int sigread) { #ifdef WITH_UML umlRegister(); #endif +#ifdef WITH_ONE + oneRegister(); +#endif #endif virEventRegisterImpl(virEventAddHandleImpl, diff --git a/src/Makefile.am b/src/Makefile.am index fd692b4..17ae0e7 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -144,6 +144,12 @@ UML_DRIVER_SOURCES = \ uml_conf.c uml_conf.h \ uml_driver.c uml_driver.h +ONE_DRIVER_SOURCES = \ + ./opennebula/one_conf.c \ + ./opennebula/one_conf.h \ + ./opennebula/one_driver.c \ + ./opennebula/one_driver.h + NETWORK_DRIVER_SOURCES = \ network_driver.h network_driver.c @@ -337,6 +342,25 @@ endif libvirt_driver_uml_la_SOURCES = $(UML_DRIVER_SOURCES) endif +if WITH_ONE +if WITH_DRIVER_MODULES +mod_LTLIBRARIES += libvirt_driver_one.la +else +noinst_LTLIBRARIES += libvirt_driver_one.la +# Stateful, so linked to daemon instead +#libvirt_la_LIBADD += libvirt_driver_one.la +endif +libvirt_driver_one_la_LDFLAGS = $(ONE_LIBS) + +if WITH_DRIVER_MODULES +libvirt_driver_one_la_LDFLAGS += -module -avoid-version +endif +libvirt_driver_one_la_SOURCES = $(ONE_DRIVER_SOURCES) +endif + + + + if WITH_NETWORK if WITH_DRIVER_MODULES mod_LTLIBRARIES += libvirt_driver_network.la @@ -429,6 +453,7 @@ EXTRA_DIST += \ $(QEMU_DRIVER_SOURCES) \ $(LXC_DRIVER_SOURCES) \ $(UML_DRIVER_SOURCES) \ + $(ONE_DRIVER_SOURCES) \ $(OPENVZ_DRIVER_SOURCES) \ $(VBOX_DRIVER_SOURCES) \ $(NETWORK_DRIVER_SOURCES) \ diff --git a/src/domain_conf.c b/src/domain_conf.c index 648d9e9..06b9713 100644 --- a/src/domain_conf.c +++ b/src/domain_conf.c @@ -55,7 +55,8 @@ VIR_ENUM_IMPL(virDomainVirt, VIR_DOMAIN_VIRT_LAST, "test", "vmware", "hyperv", - "vbox") + "vbox", + "one") VIR_ENUM_IMPL(virDomainBoot, VIR_DOMAIN_BOOT_LAST, "fd", diff --git a/src/domain_conf.h b/src/domain_conf.h index f4eea6b..c91a245 100644 --- a/src/domain_conf.h +++ b/src/domain_conf.h @@ -49,6 +49,7 @@ enum virDomainVirtType { VIR_DOMAIN_VIRT_VMWARE, VIR_DOMAIN_VIRT_HYPERV, VIR_DOMAIN_VIRT_VBOX, + VIR_DOMAIN_VIRT_ONE, VIR_DOMAIN_VIRT_LAST, }; diff --git a/src/driver.h b/src/driver.h index 39dc413..5685783 100644 --- a/src/driver.h +++ b/src/driver.h @@ -21,6 +21,7 @@ typedef enum { VIR_DRV_LXC = 6, VIR_DRV_UML = 7, VIR_DRV_VBOX = 8, + VIR_DRV_ONE = 9, } virDrvNo; diff --git a/src/libvirt.c b/src/libvirt.c index 95a861e..4b1610a 100644 --- a/src/libvirt.c +++ b/src/libvirt.c @@ -845,6 +845,10 @@ virGetVersion(unsigned long *libVer, const char *type, if (STRCASEEQ(type, "UML")) *typeVer = LIBVIR_VERSION_NUMBER; #endif +#if WITH_ONE + if (STRCASEEQ(type, "ONE")) + *typeVer = LIBVIR_VERSION_NUMBER; +#endif #if WITH_REMOTE if (STRCASEEQ(type, "Remote")) *typeVer = remoteVersion(); diff --git a/src/virterror.c b/src/virterror.c index 2d34ed7..d4b429c 100644 --- a/src/virterror.c +++ b/src/virterror.c @@ -156,6 +156,9 @@ static const char *virErrorDomainName(virErrorDomain domain) { break; case VIR_FROM_VBOX: dom = "VBOX "; + break; + case VIR_FROM_ONE: + dom = "ONE "; break; } return(dom);

On Wed, Apr 22, 2009 at 05:03:41PM +0200, "Abel M?guez Rodr?guez" wrote:
Hi all,
Here is the One driver & patches for the current git's master commit "9e9527 - Remove stale QEMU pidfiles".
[PATCH 1/2] Patch to be applied to libvirt-0.6.2 sources and building files. [PATCH 2/2] Driver source code.
Thanks for all the comments about the patches. We waited for the libvirt's release to update the driver's structure to 0.6.2 and apply the improvements. Here is a short list of the main changes applied:
- Included driver's files in a different directory "src/opennebula"
- Added Capabilities "virCapabilitiesAddGuest" for "x86_64" and "i686" guests and used "one" as hypervisor at "virCapabilitiesAddGuestDomain".
- Instead creating a temporal file to send the VM definition we have updated the API we were using to being able to do everything in memory, so making use of "virBuffer" to create the VM definition Template.
- Added previously unsupported features to the ONE Template, other types of disks and graphics (vnc,sdl) settings.
- Fixed up warnings at compilation and make 'syntax-check' test passed.
Sorry for the delay in reviewing this patch. It all looks alot better now, and pretty close to ready for commit. There is just one question I have though - when the driver initially starts up, there does not seem to be any code to populate the list of existing running VMs. ie, nothing loads data into driver->domains So it only appears to remember domains you've started via libvirt since opening the connection. My inclination at this point is to merge the driver and then we can do incremental patches to fix further problems as they arise. 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 :|

On Wed, May 20, 2009 at 11:32:18AM +0100, Daniel P. Berrange wrote:
On Wed, Apr 22, 2009 at 05:03:41PM +0200, "Abel M?guez Rodr?guez" wrote:
Hi all,
Here is the One driver & patches for the current git's master commit "9e9527 - Remove stale QEMU pidfiles".
[PATCH 1/2] Patch to be applied to libvirt-0.6.2 sources and building files. [PATCH 2/2] Driver source code.
Thanks for all the comments about the patches. We waited for the libvirt's release to update the driver's structure to 0.6.2 and apply the improvements. Here is a short list of the main changes applied:
- Included driver's files in a different directory "src/opennebula"
- Added Capabilities "virCapabilitiesAddGuest" for "x86_64" and "i686" guests and used "one" as hypervisor at "virCapabilitiesAddGuestDomain".
- Instead creating a temporal file to send the VM definition we have updated the API we were using to being able to do everything in memory, so making use of "virBuffer" to create the VM definition Template.
- Added previously unsupported features to the ONE Template, other types of disks and graphics (vnc,sdl) settings.
- Fixed up warnings at compilation and make 'syntax-check' test passed.
Sorry for the delay in reviewing this patch. It all looks alot better now, and pretty close to ready for commit.
There is just one question I have though - when the driver initially starts up, there does not seem to be any code to populate the list of existing running VMs. ie, nothing loads data into driver->domains So it only appears to remember domains you've started via libvirt since opening the connection.
My inclination at this point is to merge the driver and then we can do incremental patches to fix further problems as they arise.
Agreed, unless Abel has a newer version to submit, I'm inclined to push it before the end of the week, 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 Wed, Apr 22, 2009 at 05:03:41PM +0200, "Abel M?guez Rodr?guez" wrote:
Hi all,
Here is the One driver & patches for the current git's master commit "9e9527 - Remove stale QEMU pidfiles".
[PATCH 1/2] Patch to be applied to libvirt-0.6.2 sources and building files. [PATCH 2/2] Driver source code.
Thanks for all the comments about the patches. We waited for the libvirt's release to update the driver's structure to 0.6.2 and apply the improvements. Here is a short list of the main changes applied:
- Included driver's files in a different directory "src/opennebula"> > - Added Capabilities "virCapabilitiesAddGuest" for "x86_64" and "i686" guests and used "one" as hypervisor at "virCapabilitiesAddGuestDomain".> > - Instead creating a temporal file to send the VM definition we have updated the API we were using to being able to do everything in memory, so making use of "virBuffer" to create the VM definition Template.
- Added previously unsupported features to the ONE Template, other types of disks and graphics (vnc,sdl) settings.
- Fixed up warnings at compilation and make 'syntax-check' test passed.
Sorry for the delay in reviewing this patch. It all looks alot better> now, and pretty close to ready for commit.
There is just one question I have though - when the driver initially starts up, there does not seem to be any code to populate the
On Wed, May 20, 2009 at 11:32:18AM +0100, Daniel P. Berrange wrote: list
of existing running VMs. ie, nothing loads data into driver->domains So it only appears to remember domains you've started via libvirt since opening the connection.
My inclination at this point is to merge the driver and then we can do incremental patches to fix further problems as they arise.
Agreed, unless Abel has a newer version to submit, I'm inclined to push it before the end of the week,
Hi, This version is right to submit. I agree, after merged, any further modification needed will be solved by patches. Related with Daniel's question, we will submit a patch to populate the running VM list at libvirt's startup. Cheers, Abel Miguez Rodriguez ---- Distributed System Architecture Group (http://dsa-research.org) GridWay, http://www.gridway.org OpenNEbula, http://www.opennebula.org

On Wed, May 20, 2009 at 04:07:12PM +0200, "Abel Míguez Rodríguez" wrote:
On Wed, May 20, 2009 at 11:32:18AM +0100, Daniel P. Berrange wrote:
[...]
Here is the One driver & patches for the current git's [...] My inclination at this point is to merge the driver and then we can do incremental patches to fix further problems as they arise.
Agreed, unless Abel has a newer version to submit, I'm inclined to push it before the end of the week,
Hi, This version is right to submit. I agree, after merged, any further modification needed will be solved by patches. Related with Daniel's question, we will submit a patch to populate the running VM list at libvirt's startup.
Okay, I have commited the current set. There is however a few things to look at relatively quickly in my opinion: - we don't build the driver by default, this is a bit against the rule we should fix this - but the build depends on the ONE development environment to be present, for example OneClient.h header - another thing to note is that OpenNebula seems to be released under the Apache-2.0 Licence, which is not a problem for tyhe LGPL, but may become a problem within qemud if we link it against a GPL (v2?) library coming from another driver. So I think we should look at improving configure.in to try to locate $ONE_LOCATION/include/OneClient.h with ONE_LOCATION coming either from the environment, or from --with-one[=DIR] optional directory location or from a predefined set of locations. Right now the driver is disabled and ONE_LOCATION is assumed from configure, but that really need to be fixed IMHO. For the Licencing problem, it's a bit tricky, is OpenNebula released only as Apache-2.0 ? If yes, then maybe at configure time a check should also been made to avoid drivers under GPL and OpenNebula to be built together. It's a bit of a pain, and hopefully I get this wrong, but I'm afraid otherwise we would be in Licence violation of the GPL2 drivers (if any are configured in, I think we have one but I can't remember which one right now). 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, First, thank you very much for improving the OpenNebula driver with your comments. I am totally agree with you suggestion about the configure.in, it should be a quick fix. Regarding the licenses, I do not really see the problem. I mean, you can link with GPL and Apache as libvirt is using LGPL. But the OpenNebula driver is not using any GPL libraries; I mean, you have to be license compatible with all the libraries you are using, but do all those libraries need to be also license compatible among them?. I am not an expert in license issues so you are probably right. So, if finally there is some kind of incompatibility with OpenNebula using Apache2, we have a couple of options: 1- use the conditional compilation. I do not like this one either 2- Change the license of the OpenNebula client API to LPGL (just the library files) 3- License the OpenNebula client API with LGPL for the libvirt project 4- Include a GPL linking exception in those libraries/drivers using GPL What do you think? Cheers Ruben On Mon, May 25, 2009 at 2:08 PM, Daniel Veillard <veillard@redhat.com> wrote:
On Wed, May 20, 2009 at 04:07:12PM +0200, "Abel Míguez Rodríguez" wrote:
On Wed, May 20, 2009 at 11:32:18AM +0100, Daniel P. Berrange wrote:
[...]
Here is the One driver & patches for the current git's [...] My inclination at this point is to merge the driver and then we can do incremental patches to fix further problems as they arise.
Agreed, unless Abel has a newer version to submit, I'm inclined to push it before the end of the week,
Hi, This version is right to submit. I agree, after merged, any further modification needed will be solved by patches. Related with Daniel's question, we will submit a patch to populate the running VM list at libvirt's startup.
Okay, I have commited the current set. There is however a few things to look at relatively quickly in my opinion: - we don't build the driver by default, this is a bit against the rule we should fix this - but the build depends on the ONE development environment to be present, for example OneClient.h header - another thing to note is that OpenNebula seems to be released under the Apache-2.0 Licence, which is not a problem for tyhe LGPL, but may become a problem within qemud if we link it against a GPL (v2?) library coming from another driver.
So I think we should look at improving configure.in to try to locate $ONE_LOCATION/include/OneClient.h with ONE_LOCATION coming either from the environment, or from --with-one[=DIR] optional directory location or from a predefined set of locations. Right now the driver is disabled and ONE_LOCATION is assumed from configure, but that really need to be fixed IMHO.
For the Licencing problem, it's a bit tricky, is OpenNebula released only as Apache-2.0 ? If yes, then maybe at configure time a check should also been made to avoid drivers under GPL and OpenNebula to be built together. It's a bit of a pain, and hopefully I get this wrong, but I'm afraid otherwise we would be in Licence violation of the GPL2 drivers (if any are configured in, I think we have one but I can't remember which one right now).
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/
-- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
-- +---------------------------------------------------------------+ 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, May 25, 2009 at 06:01:06PM +0200, Ruben S. Montero wrote:
Hi Daniel,
First, thank you very much for improving the OpenNebula driver with your comments. I am totally agree with you suggestion about the configure.in, it should be a quick fix.
Okay :-)
Regarding the licenses, I do not really see the problem. I mean, you can link with GPL and Apache as libvirt is using LGPL. But the
My recollection is that the daemon is linking against a GPL library and as a result the libvirt code and the drivers included in the daemon end up being under the GPL, the library itself is still LGPL, so the problem is not for programs linking to libvirt but just for the libvirtd daemon. Since I wanted to make sure, I looked back in the archives: http://www.mail-archive.com/libvir-list@redhat.com/msg09486.html the GPL problem was with HAL and DBus, which are available under GPL *or ASL*, so my recollection was partial, and I think there is no real problem, as OpenNebula is available under ASL too. However it could still be a good idea to try to align OpenNebula client API Licence with (L)GPL if you have the possibility to do this, as libvirt daemon support for various pieces of low level infrastructure expands, this means linking with low level libraries which are frequently provided under GPL or LGPL, it would be annoying to inadvertently raise a Licence conflict as we expands libvirt capabilities.
OpenNebula driver is not using any GPL libraries; I mean, you have to be license compatible with all the libraries you are using, but do all those libraries need to be also license compatible among them?. I am not an expert in license issues so you are probably right.
So, if finally there is some kind of incompatibility with OpenNebula using Apache2, we have a couple of options:
1- use the conditional compilation. I do not like this one either 2- Change the license of the OpenNebula client API to LPGL (just the library files) 3- License the OpenNebula client API with LGPL for the libvirt project 4- Include a GPL linking exception in those libraries/drivers using GPL
I think 2, 3 or 4 would be just fine from purely a libvirt POV. I don't know the community using the OpenNebula client API, I guess if you start doing some change to the License, maybe it's worth asking them as 2 or 4 might be very interesting for them too. That doesn't need to be rushed, there is a potential issue here but it's more long-term and rather a matter of alignment. thanks for looking and your feedback ! 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 Mon, May 25, 2009 at 06:01:06PM +0200, Ruben S. Montero wrote:
Hi Daniel,
First, thank you very much for improving the OpenNebula driver with your comments. I am totally agree with you suggestion about the configure.in, it should be a quick fix.
Regarding the licenses, I do not really see the problem. I mean, you can link with GPL and Apache as libvirt is using LGPL. But the OpenNebula driver is not using any GPL libraries; I mean, you have to be license compatible with all the libraries you are using, but do all those libraries need to be also license compatible among them?. I am not an expert in license issues so you are probably right.
Yes, they do need to all be license compatible. The way in which the LGPL is is compatible with GPL, is because it allows the work to be relicensed from LGPL to GPL " 3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. " So if libvirt links to Apache licensed code, it would no longer be possible to remain in compliance with this part of the LGPL license. *Unless*, we decide to stop supporting GPL/LGPLv2-only apops, and use LGPLv3+ instead, since v3 is explicitly compatible with Apache 2
So, if finally there is some kind of incompatibility with OpenNebula using Apache2, we have a couple of options:
1- use the conditional compilation. I do not like this one either
This does not solve the license problem, just makes it worse because now effective license compatability changes according to compile options :-(
2- Change the license of the OpenNebula client API to LPGL (just the library files) 3- License the OpenNebula client API with LGPL for the libvirt project 4- Include a GPL linking exception in those libraries/drivers using GPL
5. Dual-license the client under Apache 2 and LGPL so apps can choose 6. talk XML RPC directly to the server and not use the client APIs 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 :|

On Tue, May 26, 2009 at 11:23:27AM +0100, Daniel P. Berrange wrote:
On Mon, May 25, 2009 at 06:01:06PM +0200, Ruben S. Montero wrote:
So, if finally there is some kind of incompatibility with OpenNebula using Apache2, we have a couple of options:
1- use the conditional compilation. I do not like this one either
This does not solve the license problem, just makes it worse because now effective license compatability changes according to compile options :-(
2- Change the license of the OpenNebula client API to LPGL (just the library files) 3- License the OpenNebula client API with LGPL for the libvirt project 4- Include a GPL linking exception in those libraries/drivers using GPL
5. Dual-license the client under Apache 2 and LGPL so apps can choose 6. talk XML RPC directly to the server and not use the client APIs
After looking at the scope of the APIs, I'm inclined to say we should take option 6. The current impl - libvirt one driver -> one C client - one C client is a wrapper around one C++ client - one C++ client talks to XMLRPC-C C++ library - XMLRPC-C C++ library is a wrapper around XMLRPC-C library So, not only do we currently have a license problem, but we're pulling in the whole C++ runtime for no particularly good reason or benefit. The APIs being invoked from the libvirt ONE driver are pretty simple - even the C++ client library is a merely couple of 100 lines of code. So I think its pretty easy to just have the libvirt one driver use xmlrpc C library directly. 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 :|

Hi, Probably the easiest way to solve this is to get rid to of the OpenNebula client library. So we do not have the license issue and, as Daniel said, we do not have to include the C++ dependencies. We'll try to send the patch ASAP. Regards Ruben On Tue, May 26, 2009 at 3:16 PM, Daniel P. Berrange <berrange@redhat.com> wrote:
On Tue, May 26, 2009 at 11:23:27AM +0100, Daniel P. Berrange wrote:
On Mon, May 25, 2009 at 06:01:06PM +0200, Ruben S. Montero wrote:
So, if finally there is some kind of incompatibility with OpenNebula using Apache2, we have a couple of options:
1- use the conditional compilation. I do not like this one either
This does not solve the license problem, just makes it worse because now effective license compatability changes according to compile options :-(
2- Change the license of the OpenNebula client API to LPGL (just the library files) 3- License the OpenNebula client API with LGPL for the libvirt project 4- Include a GPL linking exception in those libraries/drivers using GPL
5. Dual-license the client under Apache 2 and LGPL so apps can choose 6. talk XML RPC directly to the server and not use the client APIs
After looking at the scope of the APIs, I'm inclined to say we should take option 6. The current impl
- libvirt one driver -> one C client - one C client is a wrapper around one C++ client - one C++ client talks to XMLRPC-C C++ library - XMLRPC-C C++ library is a wrapper around XMLRPC-C library
So, not only do we currently have a license problem, but we're pulling in the whole C++ runtime for no particularly good reason or benefit. The APIs being invoked from the libvirt ONE driver are pretty simple - even the C++ client library is a merely couple of 100 lines of code. So I think its pretty easy to just have the libvirt one driver use xmlrpc C library directly.
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 :|
-- +---------------------------------------------------------------+ 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 Tue, May 26, 2009 at 04:26:36PM +0200, Ruben S. Montero wrote:
Hi,
Probably the easiest way to solve this is to get rid to of the OpenNebula client library. So we do not have the license issue and, as Daniel said, we do not have to include the C++ dependencies.
We'll try to send the patch ASAP.
Okay, thanks ! Ideally by Friday since I will release 0.6.4 then, if we could have this fixed before the realease that would be great :-) Daniel
On Tue, May 26, 2009 at 3:16 PM, Daniel P. Berrange <berrange@redhat.com> wrote: [...]
6. talk XML RPC directly to the server and not use the client APIs
After looking at the scope of the APIs, I'm inclined to say we should take option 6. The current impl
- libvirt one driver -> one C client - one C client is a wrapper around one C++ client - one C++ client talks to XMLRPC-C C++ library - XMLRPC-C C++ library is a wrapper around XMLRPC-C library
So, not only do we currently have a license problem, but we're pulling in the whole C++ runtime for no particularly good reason or benefit. The APIs being invoked from the libvirt ONE driver are pretty simple - even the C++ client library is a merely couple of 100 lines of code. So I think its pretty easy to just have the libvirt one driver use xmlrpc C library directly.
Regards, 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, Right now most of us are out of the office, so we will be able to send the patches by next week. Sorry for this delay :( Ruben On Wed, May 27, 2009 at 10:45 AM, Daniel Veillard <veillard@redhat.com> wrote:
On Tue, May 26, 2009 at 04:26:36PM +0200, Ruben S. Montero wrote:
Hi,
Probably the easiest way to solve this is to get rid to of the OpenNebula client library. So we do not have the license issue and, as Daniel said, we do not have to include the C++ dependencies.
We'll try to send the patch ASAP.
Okay, thanks ! Ideally by Friday since I will release 0.6.4 then, if we could have this fixed before the realease that would be great :-)
Daniel
On Tue, May 26, 2009 at 3:16 PM, Daniel P. Berrange <berrange@redhat.com> wrote: [...]
6. talk XML RPC directly to the server and not use the client APIs
After looking at the scope of the APIs, I'm inclined to say we should take option 6. The current impl
- libvirt one driver -> one C client - one C client is a wrapper around one C++ client - one C++ client talks to XMLRPC-C C++ library - XMLRPC-C C++ library is a wrapper around XMLRPC-C library
So, not only do we currently have a license problem, but we're pulling in the whole C++ runtime for no particularly good reason or benefit. The APIs being invoked from the libvirt ONE driver are pretty simple - even the C++ client library is a merely couple of 100 lines of code. So I think its pretty easy to just have the libvirt one driver use xmlrpc C library directly.
Regards, 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/
-- +---------------------------------------------------------------+ 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, May 25, 2009 at 02:08:53PM +0200, Daniel Veillard wrote:
On Wed, May 20, 2009 at 04:07:12PM +0200, "Abel Míguez Rodríguez" wrote:
On Wed, May 20, 2009 at 11:32:18AM +0100, Daniel P. Berrange wrote:
[...]
Here is the One driver & patches for the current git's [...] My inclination at this point is to merge the driver and then we can do incremental patches to fix further problems as they arise.
Agreed, unless Abel has a newer version to submit, I'm inclined to push it before the end of the week,
Hi, This version is right to submit. I agree, after merged, any further modification needed will be solved by patches. Related with Daniel's question, we will submit a patch to populate the running VM list at libvirt's startup.
Okay, I have commited the current set. There is however a few things to look at relatively quickly in my opinion: - we don't build the driver by default, this is a bit against the rule we should fix this - but the build depends on the ONE development environment to be present, for example OneClient.h header - another thing to note is that OpenNebula seems to be released under the Apache-2.0 Licence, which is not a problem for tyhe LGPL, but may become a problem within qemud if we link it against a GPL (v2?) library coming from another driver.
This is a bit of a pain. Apache 2 is not compatible with GPL v2, only with GPL v3. Although the libvirtd source is LGPL, the resulting combined work is GPLv2 due to the set of libraries we link against, in particular DBus. Also a number of applications using libvirt are GPL licensed such as virt-manager. Fortunately I think they're all v2+, not v2-only. The GPL v3 addresses the Apache 2 compatability problem. So if we include the OpenNebula driver the only way we can remain compliant is to say that libvirt is now LGPL v3+ licensed, and explicitly exclude any usage in GPLv2-only/LGPLv2-only applications. GPLv2+/ LGPLv2+ are of course OK, since they "upgrade" to GPLv3/LGPLv3.
For the Licencing problem, it's a bit tricky, is OpenNebula released only as Apache-2.0 ? If yes, then maybe at configure time a check should also been made to avoid drivers under GPL and OpenNebula to be built together. It's a bit of a pain, and hopefully I get this wrong, but I'm afraid otherwise we would be in Licence violation of the GPL2 drivers (if any are configured in, I think we have one but I can't remember which one right now).
Having the effective licensing of libvirt change according to compile options is a total disaster :-( We need to have clearly defined licensing no matter what compile options are used. So if we want to distribute the OpenNebula driver as is, IMHO we need to change libvirt to explicitly be LGPLv3+ licensed. Otherwise we should remove this driver code, until we can get a LGPLv2 compatible licensed driver. 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 :|
participants (5)
-
"Abel Míguez Rodríguez"
-
Daniel P. Berrange
-
Daniel Veillard
-
Pritesh Kothari
-
Ruben S. Montero