On 05/15/2013 04:33 AM, Daniel P. Berrange wrote:
From: "Daniel P. Berrange" <berrange(a)redhat.com>
Change the build process & driver initialization so that the
VirtualBox driver is built into libvirtd, instead of libvirt.so
This change avoids the VirtualBox GPLv2-only license causing
compatibility problems with libvirt.so which is under the
GPLv2-or-later license.
NB this change prevents use of the VirtualBox driver on the
Windows platform, until such time as libvirtd can be made
to work there.
Do we still know what is needed to get libvirtd working on Windows? But
I agree that we need this change for the sake of GPLv3 users of libvirt.so.
Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com>
---
daemon/libvirtd.c | 9 +++++++++
docs/drvvbox.html.in | 12 ++++++++++++
src/Makefile.am | 24 +++++++++++++++++++-----
src/libvirt.c | 7 -------
4 files changed, 40 insertions(+), 12 deletions(-)
+ <p>
+ <strong>NOTE: as of libvirt 1.0.6, the VirtualBox driver will always
+ run inside the libvirtd daemon, instead of being built-in to the
+ libvirt.so library directly. This change was required due to the
+ fact that VirtualBox code is GPLv2-only licensed, which is not
+ compatible with the libvirt.so license of GPLv2-or-later. The
+ daemon will be auto-started when the first connection to VirtualBox
In other words, the vbox:// URI is treated like qemu:///session, in that
you don't have to have a libvirtd system daemon running?
+ is requested. This change also means it is no longer
possible to
+ use the VirtualBox on the Windows platform, which lacks support
+ for the libvirtd daemon.</strong>
Maybe word this last sentence a bit more optimistically:
This change also means that it is temporarily not possible to use
VirtualBox URIs on the Windows platform, until additional work is
completed to get the libvirtd daemon working there.
Looks okay to me once you address Michal's findings.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org