[Libvir] Linker dependancoes [Re: [kvm-devel] QEMU / KVM support in libvirt & virt-manager]
See this thread on kvm-devel for a question about link time dependancies in libvirt. I'm not sure what the optimal approach is for us to deal with this is - just something we should think about in an idle moment... ----- Forwarded message from Avi Kivity <avi@qumranet.com> -----
Date: Sun, 25 Feb 2007 18:48:44 +0200 From: Avi Kivity <avi@qumranet.com> To: "Daniel P. Berrange" <berrange@redhat.com> CC: kvm-devel@lists.sourceforge.net Subject: Re: [kvm-devel] QEMU / KVM support in libvirt & virt-manager
Daniel P. Berrange wrote:
On Sun, Feb 25, 2007 at 07:32:58AM +0200, Avi Kivity wrote:
Daniel P. Berrange wrote:
FYI, as of libvirt 0.2.0 and virt-manager 0.3.1 there is now (experimental!) support for managing virtual machines running under QEMU or KVM virtualization platforms, as well as the existing Xen support.
Great; as I see it hit FC6-updates I'll give it a shot.
One thing I saw is that it pulls in Xen as part of the dependencies; perhaps a libvirt-xen and libvirt-kvm subpackage split is called for?
Yeah, we've not figured out exactly how to address that dependancy issue yet - the libvirt.so has to link to libxenstore as part of the Xen driver, so even if you only want to manage QEMU instances we still end up pulling in Xen. We're certainly going to make it possible to turn off the Xen stuff at compile time. Not clear how we'd address the RPM dep issue though because the Fedora builds of libvirt will include both Xen & QEMU support. Perhaps we'll have to try a dlopen() approach.
I would suggest a /usr/lib/libvirt/xen.so and a /usr/lib/libvirt/qemu.so, which are enumerated by reading /usr/lib/libvirt, and dlopen()ed by libvirt.so. Only /usr/lib/libvirt/xen.so links to libxenstore.
That way, a third party can add a backend by dropping a .so into /usr/lib/libvirt, and libvirt.so itself has no backend-related dependencies -- it doesn't know anything concrete about the backends, in fact. ----- End forwarded message -----
Dan -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
On Sun, Feb 25, 2007 at 08:48:12PM +0000, Daniel P. Berrange wrote:
See this thread on kvm-devel for a question about link time dependancies in libvirt. I'm not sure what the optimal approach is for us to deal with this is - just something we should think about in an idle moment...
Definitely (... it would be best for FC7, no later.) The libvirt already uses exactly defined API (struct virDriver). I think it's a possible food for dlopen(). The rpm could be divided to multiple subpackages: libvirt.rpm libvirt-driver-xen.rpm libvirt-driver-qemu.rpm libvirt-driver-kvm.rpm Karel
Yeah, we've not figured out exactly how to address that dependancy issue yet - the libvirt.so has to link to libxenstore as part of the Xen driver, so even if you only want to manage QEMU instances we still end up pulling in Xen. We're certainly going to make it possible to turn off the Xen stuff at compile time. Not clear how we'd address the RPM dep issue though because the Fedora builds of libvirt will include both Xen & QEMU support. Perhaps we'll have to try a dlopen() approach.
I would suggest a /usr/lib/libvirt/xen.so and a /usr/lib/libvirt/qemu.so, which are enumerated by reading /usr/lib/libvirt, and dlopen()ed by libvirt.so. Only /usr/lib/libvirt/xen.so links to libxenstore.
That way, a third party can add a backend by dropping a .so into /usr/lib/libvirt, and libvirt.so itself has no backend-related dependencies -- it doesn't know anything concrete about the backends, in fact.
-- Karel Zak <kzak@redhat.com>
On Mon, 2007-02-26 at 00:07 +0100, Karel Zak wrote:
On Sun, Feb 25, 2007 at 08:48:12PM +0000, Daniel P. Berrange wrote:
See this thread on kvm-devel for a question about link time dependancies in libvirt. I'm not sure what the optimal approach is for us to deal with this is - just something we should think about in an idle moment...
Definitely (... it would be best for FC7, no later.)
The libvirt already uses exactly defined API (struct virDriver). I think it's a possible food for dlopen(). The rpm could be divided to multiple subpackages:
libvirt.rpm libvirt-driver-xen.rpm libvirt-driver-qemu.rpm libvirt-driver-kvm.rpm
From a packaging point of view, this seems like the sanest approach; note though that somebody (hopefully not the user) has to jump through some hoops to make sure that their installed libvirt drivers match their installed virt infrastructure. One way to do that would be to make the xen (or kernel-xen ?) package depend on libvirt-driver-xen etc.
David
On Sun, 2007-02-25 at 20:48 +0000, Daniel P. Berrange wrote:
See this thread on kvm-devel for a question about link time dependancies in libvirt. I'm not sure what the optimal approach is for us to deal with this is - just something we should think about in an idle moment...
The driver API makes this really easy for us - would just need an init function (or list of functions) in each driver module which would just call back into virRegister[Network]Driver() (Of course, we'd still keep the driver API private and only allow driver modules from libvirt itself.) Cheers, Mark.
participants (4)
-
Daniel P. Berrange -
David Lutterkort -
Karel Zak -
Mark McLoughlin