On Wed, May 01, 2013 at 06:24:00PM +0200, Matthias Bolte wrote: > 2013/5/1 Eric Blake <eblake@xxxxxxxxxx>: > > Implementation wise, this would mean that we compile the vbox driver as > > an independent module (much the same as we do for qemu or lxc), and link > > that module into libvirtd rather than into libvirt.so directly. In > > libvirt.so, attempts to use a vbox:// URI would then be forwarded over > > RPC to libvirtd, instead of directly using vbox code. vbox would then > > be a remote instead of a local protocol. Since existing vbox:// > > connections are local, vbox users have not previously had to ensure that > > the system libvirtd daemon is running. Therefore, I suspect that it > > would be nicer to reuse the qemu://session code that auto-spawns a > > session libvirtd, so that from the user standpoint, they can continue to > > connect to vbox without having to have a libvirtd system daemon running. > > The initial connection time will take slightly longer as a session > > libvirtd is autospawned, but that should not be too much impact. > > This will break Virtual Box support on Windows, because libvirtd > doesn't work on Windows yet. NB, if moving virtualbox into libvirtd is not possible, then the only other option on the table right now to solve the license compatibility issues to delete all virtual box code from libvirt. So loosing support for Windows might be the price we have to pay, and/or motivation to port libvirtd to work on Windows. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list