Re: [libvirt] [PATCH 00/10] Enable loadable modules for libvirtd
On Mon, Apr 02, 2012 at 08:57:11PM +0100, Daniel P. Berrange wrote: For a long timer we've had the ability to build each libvirt driver as a loadable module. We have never used this by default and as a result it constantly bit-rots. This series fixes various bugs, and then enables it by default in configure. It also makes the PRMs use the loadable modules, adding new new sub-RPMs for each module. We can now finally install minimal libvirt binaries for each hypervisor. ie yum install libvirt-kvm will not pull in Xen libraries! Okay, I understand the principle, and this sounds good. I'm sorry for not having caught up the RPM server refactoring patch earlier, I would have discussed that scenario, and would have avoided me reverting your patch (I really dislike doing this, I guess that was the first time I ever did this) but this was IMHO too much change and too early. I completely agree with the scenario of being able to do yum install libvirt-kvm and have libvirt daemon, the bits for the daemon qemu/kvm support, and related configuration files being pulled in, as well as hooking up the hypervisor dependency. But to me that means one specific libvirt-kvm package (tied to the daemon anyway the client should be agnostic about it), not two ! We should aim at minimizing the number of actual packages while still providing the needed modularization. So I would expect: - libvirt (the server and its basic config file) - libvirt-client (as usual) - libvirt-kvm (can we merge -kvm and -qemu ?) - libvirt-xen - libvirt-lxc - libvirt-uml - libvirt-network (our default network config) - libvirt-devel (as usual) - libvirt-lock-sanlock (as usual) - libvirt-python (as usual) for a separate split of the documentation currently in the -devel package I'm not so sure it's worth changing but I don't have a strong opinion Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@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
Re: [libvirt] [PATCH 00/10] Enable loadable modules for libvirtd
On Tue, Apr 03, 2012 at 04:22:59PM +0800, Daniel Veillard wrote: On Mon, Apr 02, 2012 at 08:57:11PM +0100, Daniel P. Berrange wrote: For a long timer we've had the ability to build each libvirt driver as a loadable module. We have never used this by default and as a result it constantly bit-rots. This series fixes various bugs, and then enables it by default in configure. It also makes the PRMs use the loadable modules, adding new new sub-RPMs for each module. We can now finally install minimal libvirt binaries for each hypervisor. ie yum install libvirt-kvm will not pull in Xen libraries! Okay, I understand the principle, and this sounds good. I'm sorry for not having caught up the RPM server refactoring patch earlier, I would have discussed that scenario, and would have avoided me reverting your patch (I really dislike doing this, I guess that was the first time I ever did this) but this was IMHO too much change and too early. I completely agree with the scenario of being able to do yum install libvirt-kvm and have libvirt daemon, the bits for the daemon qemu/kvm support, and related configuration files being pulled in, as well as hooking up the hypervisor dependency. But to me that means one specific libvirt-kvm package (tied to the daemon anyway the client should be agnostic about it), not two ! We should aim at minimizing the number of actual packages while still providing the needed modularization. So I would expect: - libvirt (the server and its basic config file) We can't do that, because changing the base 'libvirt' RPM in this way will break the upgrade path - we need semantics of doing 'yum install libvirt' to remain unchanged from before. - libvirt-client (as usual) - libvirt-devel (as usual) - libvirt-lock-sanlock (as usual) - libvirt-python (as usual) Indeed, there was/is no need to change the client side parts - only the server side. - libvirt-kvm (can we merge -kvm and -qemu ?) It is not desirable to merge them. In Fedora we don't want to force the install of all the QEMU emulators - we only want to pull in the qemu-kvm emulator most of the time. If apps depend on libvirt-kvm, they will get only the KVM stack, while if they depend on libvirt-qemu they will get the full QEMU stack. In RHEL of course there is no QEMU so that sub-RPM disappears. - libvirt-xen - libvirt-lxc - libvirt-uml - libvirt-network (our default network config) We need each dlopen'd .so file to be in a separate RPM. eg so that when you install KVM, you don't pull in xen-libs. As well as the hypervisor drivers though, you have the other pieces like the network/storage/nodedev drivers. As well as the need to split the virbr0 / nwfilter config files out, we get a minimum RPM set with actual %file payloads: - libvirt-daemon - Just the libvirtd daemon, no drivers, no configs - libvirt-daemon-config-network - Just the virbr0 configs - libvirt-daemon-config-nwfilter - Just the firewall configs - libvirt-daemon-driver-XXX - Contains the dlopen'd modules per driver or sub-driver. One for each XXX in: (uml, qemu, xen, lxc, storage, network, nwfilter, interface, nodedev, secrets) For the sake of backwards compatibility / upgrade path we need: - libvirt - Virtual RPM, which Requires all of the above RPMs, to ensure that it pulls in everything that the old libvirt RPM always had. Sice it would be really tedious for apps to have to list Requires: on each libvirt-daemon-driver-XXX module they care about we introduced (and that would be upgrade-safe if we introduce more sub-drivers), we need virtual packages: - libvirt-daemon-YYY - Virtual RPM pulls in the set of drivers required for a specific hypervisor. One for each YYY in (uml, qemu, kvm, xen, lxc). Also depends on the appropriate hypervisr RPM (eg 'qemu', 'qemu-kvm', 'xen') - libvirt-YYY - Virtual RPMs to pull in the set of drivers required for a specific hypervisor, plus the default config files. One for each YYY in (uml, qemu, kvm, xen, lxc). I can see an argument that having 2 sets of virtual packages here is a little bit overkill. Apps could just have added Requires: libvirt-daemon-kvm, libvirt-ademon-config-network if they really want KVM and the default configs. So we could get rid of one of these virtual package sets without any real loss of flexibility. I don't see how we can practically eliminate any other sub-RPMS besides these two, while retained flexibility upon install for a separate split of the documentation currently in the -devel package I'm not so sure it's worth changing but I don't have a strong
Re: [libvirt] [PATCH 00/10] Enable loadable modules for libvirtd
On Tue, Apr 03, 2012 at 10:06:02AM +0100, Daniel P. Berrange wrote: On Tue, Apr 03, 2012 at 04:22:59PM +0800, Daniel Veillard wrote: On Mon, Apr 02, 2012 at 08:57:11PM +0100, Daniel P. Berrange wrote: For a long timer we've had the ability to build each libvirt driver as a loadable module. We have never used this by default and as a result it constantly bit-rots. This series fixes various bugs, and then enables it by default in configure. It also makes the PRMs use the loadable modules, adding new new sub-RPMs for each module. We can now finally install minimal libvirt binaries for each hypervisor. ie yum install libvirt-kvm will not pull in Xen libraries! Okay, I understand the principle, and this sounds good. I'm sorry for not having caught up the RPM server refactoring patch earlier, I would have discussed that scenario, and would have avoided me reverting your patch (I really dislike doing this, I guess that was the first time I ever did this) but this was IMHO too much change and too early. I completely agree with the scenario of being able to do yum install libvirt-kvm and have libvirt daemon, the bits for the daemon qemu/kvm support, and related configuration files being pulled in, as well as hooking up the hypervisor dependency. But to me that means one specific libvirt-kvm package (tied to the daemon anyway the client should be agnostic about it), not two ! We should aim at minimizing the number of actual packages while still providing the needed modularization. So I would expect: - libvirt (the server and its basic config file) We can't do that, because changing the base 'libvirt' RPM in this way will break the upgrade path - we need semantics of doing 'yum install libvirt' to remain unchanged from before. okay, libvirt is the server package, that is full blown version... we can't change that, you're right ! - libvirt-client (as usual) - libvirt-devel (as usual) - libvirt-lock-sanlock (as usual) - libvirt-python (as usual) Indeed, there was/is no need to change the client side parts - only the server side. - libvirt-kvm (can we merge -kvm and -qemu ?) It is not desirable to merge them. In Fedora we don't want to force the install of all the QEMU emulators - we only want to pull in the qemu-kvm emulator most of the time. If apps depend on libvirt-kvm, they will get only the KVM stack, while if they depend on libvirt-qemu they will get the full QEMU stack. In RHEL of course there is no QEMU so that sub-RPM disappears. okay, let's keep that split, that's 2 different audiences anyway, but I would expect then to share the same .so for the driver - libvirt-xen - libvirt-lxc - libvirt-uml - libvirt-network (our default network config) We need each dlopen'd .so file to be in a separate RPM. eg so that when you install KVM, you don't pull in xen-libs. As well as the hypervisor drivers though, you have the other pieces like the network/storage/nodedev drivers. As well as the need to split the virbr0 / nwfilter config files out, we get a minimum RPM set with actual %file payloads: - libvirt-daemon - Just the libvirtd daemon, no drivers, no configs - libvirt-daemon-config-network - Just the virbr0 configs let's rename to libvirt-daemon-bridge then ! - libvirt-daemon-config-nwfilter - Just the firewall configs and libvirt-daemon-nwfilter the fact that the rpm contains config files, or .so, or binaries the user should care only of what functionality is provided. If we split it that much then we must make sure that rpm -i libvirt-daemon-nwfilter will actually restart the server in the %post (and true for most of the others package, may turn into a challenge when installing 4 extension package and we want to avoid restarting the server 4 times !) - libvirt-daemon-driver-XXX - Contains the dlopen'd modules per driver or sub-driver. One for each XXX in: (uml, qemu, xen, lxc, storage, network, nwfilter, interface, nodedev, secrets) this is what I dislike, I would prefer to see libvirt-kvm and libvirt-daemon-driver-kvm to be merged (and hence my question about qemu and kvm because the .so would be shared I assume) unless there is a good story for having only the .so in the rpm that's the part I really reacted to when I made my tentative build for the release and that looks way to intricate to my taste. For the sake of backwards compatibility / upgrade path we need: - libvirt - Virtual RPM, which Requires all of the above RPMs, to ensure that it pulls in everything that the old libvirt RPM always had. I really dislike virtual rpms . When we splitted -client and the server part we reassigned the server part to the old package, and that worked well since we still had the full dependency
Re: [libvirt] [PATCH 00/10] Enable loadable modules for libvirtd
On Tue, Apr 03, 2012 at 05:41:57PM +0800, Daniel Veillard wrote: On Tue, Apr 03, 2012 at 10:06:02AM +0100, Daniel P. Berrange wrote: On Tue, Apr 03, 2012 at 04:22:59PM +0800, Daniel Veillard wrote: - libvirt-daemon - Just the libvirtd daemon, no drivers, no configs - libvirt-daemon-config-network - Just the virbr0 configs let's rename to libvirt-daemon-bridge then ! No, I explicitly chose to have -config' in the name, because this really is just the config files, and we might want to use the name 'libvirt-daemon-bridge' at some point in the future. - libvirt-daemon-config-nwfilter - Just the firewall configs and libvirt-daemon-nwfilter Again, I want config there to ensure that the libvirt-ademon-nwfilter RPM name is availble for future use. the fact that the rpm contains config files, or .so, or binaries the user should care only of what functionality is provided. The actual nwfilter functionality is provided in the libvirt-daemon RPM, so to suggest they need to use libvirt-daemon-nwfilter is misleading - this is only some default config files which apps do not need to use if they don't want them - oVirt uses its own configs for example. If we split it that much then we must make sure that rpm -i libvirt-daemon-nwfilter will actually restart the server in the %post (and true for most of the others package, may turn into a challenge when installing 4 extension package and we want to avoid restarting the server 4 times !) In the re-post I did, I use %posttrans script to ensure it is restarted once, at the end of the transaction. - libvirt-daemon-driver-XXX - Contains the dlopen'd modules per driver or sub-driver. One for each XXX in: (uml, qemu, xen, lxc, storage, network, nwfilter, interface, nodedev, secrets) this is what I dislike, I would prefer to see libvirt-kvm and libvirt-daemon-driver-kvm to be merged (and hence my question about qemu and kvm because the .so would be shared I assume) unless there is a good story for having only the .so in the rpm that's the part I really reacted to when I made my tentative build for the release and that looks way to intricate to my taste. It is not possible to merge these to. For backwards compatibility, we need 'libvirt' to depend on 'libvirt-daemon-driver-qemu'. We do *not*, however, want 'libvirt' to pull in 'qemu' itself. It becomes clear when you consider what the entry points for application dependancies are: /--- libvirt +- libvirt-daemon | | ^ | | | | \- libvirt-daemon-driver-qemu | | | +--- libvirt-daemon-qemu +--|-- qemu || +--- libvirt-daemon-kvm +-- qemu-kvm | App Choice So 'yum install libvirt', does *not* pull in 'qemu', 'qemu-kvm' or 'xen' If we merged the packages as you describe, we'd end up with /--- libvirt +- libvirt-daemon | | ^ | \-\| || || || V| ||-- libvirt-daemon-driver-qemu --- qemu || |\--\ | | | V |--- libvirt-daemon-driver-qemu --- qemu-kvm | App Choice So, 'yum install libvirt' would end up pulling in every single hypervisor we support (qemu, qemu-kvm, xen), which is not at all what we want. Separating the libvirt-daemon-XXX packages from the libvirt-daemon-driver-XXX packages is key to achieving the goal of minimising install footprint, while maintaining backwards compatibility with existing RPM deps. Rgards, 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@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 00/10] Enable loadable modules for libvirtd
On Tue, Apr 03, 2012 at 02:08:11PM +0100, Daniel P. Berrange wrote: On Tue, Apr 03, 2012 at 05:41:57PM +0800, Daniel Veillard wrote: On Tue, Apr 03, 2012 at 10:06:02AM +0100, Daniel P. Berrange wrote: On Tue, Apr 03, 2012 at 04:22:59PM +0800, Daniel Veillard wrote: - libvirt-daemon - Just the libvirtd daemon, no drivers, no configs - libvirt-daemon-config-network - Just the virbr0 configs let's rename to libvirt-daemon-bridge then ! No, I explicitly chose to have -config' in the name, because this really is just the config files, and we might want to use the name 'libvirt-daemon-bridge' at some point in the future. - libvirt-daemon-config-nwfilter - Just the firewall configs and libvirt-daemon-nwfilter Again, I want config there to ensure that the libvirt-ademon-nwfilter RPM name is availble for future use. the fact that the rpm contains config files, or .so, or binaries the user should care only of what functionality is provided. The actual nwfilter functionality is provided in the libvirt-daemon RPM, so to suggest they need to use libvirt-daemon-nwfilter is misleading - this is only some default config files which apps do not need to use if they don't want them - oVirt uses its own configs for example. okay ... If we split it that much then we must make sure that rpm -i libvirt-daemon-nwfilter will actually restart the server in the %post (and true for most of the others package, may turn into a challenge when installing 4 extension package and we want to avoid restarting the server 4 times !) In the re-post I did, I use %posttrans script to ensure it is restarted once, at the end of the transaction. good ! - libvirt-daemon-driver-XXX - Contains the dlopen'd modules per driver or sub-driver. One for each XXX in: (uml, qemu, xen, lxc, storage, network, nwfilter, interface, nodedev, secrets) this is what I dislike, I would prefer to see libvirt-kvm and libvirt-daemon-driver-kvm to be merged (and hence my question about qemu and kvm because the .so would be shared I assume) unless there is a good story for having only the .so in the rpm that's the part I really reacted to when I made my tentative build for the release and that looks way to intricate to my taste. It is not possible to merge these to. For backwards compatibility, we need 'libvirt' to depend on 'libvirt-daemon-driver-qemu'. We do *not*, however, want 'libvirt' to pull in 'qemu' itself. It becomes clear when you consider what the entry points for application dependancies are: /--- libvirt +- libvirt-daemon | | ^ | | | | \- libvirt-daemon-driver-qemu | | | +--- libvirt-daemon-qemu +--|-- qemu || +--- libvirt-daemon-kvm +-- qemu-kvm | App Choice So 'yum install libvirt', does *not* pull in 'qemu', 'qemu-kvm' or 'xen' If we merged the packages as you describe, we'd end up with /--- libvirt +- libvirt-daemon | | ^ | \-\| || || || V| ||-- libvirt-daemon-driver-qemu --- qemu || |\--\ | | | V |--- libvirt-daemon-driver-qemu --- qemu-kvm | App Choice So, 'yum install libvirt' would end up pulling in every single hypervisor we support (qemu, qemu-kvm, xen), which is not at all what we want. Separating the libvirt-daemon-XXX packages from the libvirt-daemon-driver-XXX packages is key to achieving the goal of minimising install footprint, while maintaining backwards compatibility with existing RPM deps. I still wonder if it is worth it then. Adding an extra empty rpm just for the sake or avoiding a explicit hypervisor dependency at the application level. The whole scheme adds N + 1 empty rpms just for avoiding that dep that the application need to explicitely state right now anyway. Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@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
Re: [libvirt] [PATCH 00/10] Enable loadable modules for libvirtd
On Tue, Apr 03, 2012 at 09:57:19PM +0800, Daniel Veillard wrote: On Tue, Apr 03, 2012 at 02:08:11PM +0100, Daniel P. Berrange wrote: So, 'yum install libvirt' would end up pulling in every single hypervisor we support (qemu, qemu-kvm, xen), which is not at all what we want. Separating the libvirt-daemon-XXX packages from the libvirt-daemon-driver-XXX packages is key to achieving the goal of minimising install footprint, while maintaining backwards compatibility with existing RPM deps. I still wonder if it is worth it then. Adding an extra empty rpm just for the sake or avoiding a explicit hypervisor dependency at the application level. The whole scheme adds N + 1 empty rpms just for avoiding that dep that the application need to explicitely state right now anyway. I think it is worth it, based on the fact that we get reasonably frequent bug reports that installing libvirt did not install qemu-kvm, or similar. Also, it avoids the need for applications to care about the different package names - eg in RHEL-5 the RPM was 'kvm', while in RHEL-6, the RPM was 'qemu-kvm', and who knows if it will change again... 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@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 00/10] Enable loadable modules for libvirtd
On Tue, Apr 03, 2012 at 03:13:54PM +0100, Daniel P. Berrange wrote: On Tue, Apr 03, 2012 at 09:57:19PM +0800, Daniel Veillard wrote: On Tue, Apr 03, 2012 at 02:08:11PM +0100, Daniel P. Berrange wrote: So, 'yum install libvirt' would end up pulling in every single hypervisor we support (qemu, qemu-kvm, xen), which is not at all what we want. Separating the libvirt-daemon-XXX packages from the libvirt-daemon-driver-XXX packages is key to achieving the goal of minimising install footprint, while maintaining backwards compatibility with existing RPM deps. I still wonder if it is worth it then. Adding an extra empty rpm just for the sake or avoiding a explicit hypervisor dependency at the application level. The whole scheme adds N + 1 empty rpms just for avoiding that dep that the application need to explicitely state right now anyway. I think it is worth it, based on the fact that we get reasonably frequent bug reports that installing libvirt did not install qemu-kvm, or similar. In practice now we ask people to install 'qemu-kvm' directly With the change we ask people to install 'libvirt-kvm' instead, I don't see such an huge improvement to be honnest, basically ths means that people must select the hypervisor at some point, whether it's at the base os install vs. at the libvirt install. Also, it avoids the need for applications to care about the different package names - eg in RHEL-5 the RPM was 'kvm', while in RHEL-6, the RPM was 'qemu-kvm', and who knows if it will change again... True but it's not like it's changing very often. Okay, I'm too hard to be convinced that it's the right way to go, can someone with a fresh mind on the issue look at it, I won't block, though I'm certainly dragging feets in case it's not clear :-) People do get lost with rpm dependencies and the whole scheme is way too complex IMHO. Now that I have exposed my belief I'm fine being put in the minority :) Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@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
Re: [libvirt] [PATCH 00/10] Enable loadable modules for libvirtd
On Tue, Apr 03, 2012 at 10:44:26PM +0800, Daniel Veillard wrote: On Tue, Apr 03, 2012 at 03:13:54PM +0100, Daniel P. Berrange wrote: On Tue, Apr 03, 2012 at 09:57:19PM +0800, Daniel Veillard wrote: On Tue, Apr 03, 2012 at 02:08:11PM +0100, Daniel P. Berrange wrote: So, 'yum install libvirt' would end up pulling in every single hypervisor we support (qemu, qemu-kvm, xen), which is not at all what we want. Separating the libvirt-daemon-XXX packages from the libvirt-daemon-driver-XXX packages is key to achieving the goal of minimising install footprint, while maintaining backwards compatibility with existing RPM deps. I still wonder if it is worth it then. Adding an extra empty rpm just for the sake or avoiding a explicit hypervisor dependency at the application level. The whole scheme adds N + 1 empty rpms just for avoiding that dep that the application need to explicitely state right now anyway. I think it is worth it, based on the fact that we get reasonably frequent bug reports that installing libvirt did not install qemu-kvm, or similar. In practice now we ask people to install 'qemu-kvm' directly With the change we ask people to install 'libvirt-kvm' instead, Almost. Currently we ask to install 'libvirt' and 'qemu-kvm', now we just need to install 'libvirt-daemon-kvm'. I don't see such an huge improvement to be honnest, basically ths means that people must select the hypervisor at some point, whether it's at the base os install vs. at the libvirt install. 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@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 00/10] Enable loadable modules for libvirtd
On 04/03/2012 08:46 AM, Daniel P. Berrange wrote: I think it is worth it, based on the fact that we get reasonably frequent bug reports that installing libvirt did not install qemu-kvm, or similar. In practice now we ask people to install 'qemu-kvm' directly With the change we ask people to install 'libvirt-kvm' instead, Almost. Currently we ask to install 'libvirt' and 'qemu-kvm', now we just need to install 'libvirt-daemon-kvm'. I think that being able to select one package instead of two is a benefit (the old way requires me to select both 'libvirt' and 'qemu-kvm' before my kvm guests work, the new way says that I want the one package 'libvirt-daemon-kvm' and I get everything needed for kvm guests). I don't see such an huge improvement to be honnest, basically ths means that people must select the hypervisor at some point, whether it's at the base os install vs. at the libvirt install. I look at it as a stack issue - I know that libvirt is in my stack, and since I want to only interact with libvirt, I _don't_ want to know what lower pieces in the stack also have to be pulled in. Having to manually select 'qemu-kvm' is a violation of the layering. For comparison, if I plan on using stdio, I want to use fopen() and fwrite() and friends from just stdio.h - I shouldn't have to care that stdio uses open() and write() and close() from unistd.h and other lower-level headers. An application using libvirt should not have to know what lower-level components to pull in, they should just pull in the appropriate libvirt package that meets their needs. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 00/10] Enable loadable modules for libvirtd
For a long timer we've had the ability to build each libvirt driver as a loadable module. We have never used this by default and as a result it constantly bit-rots. This series fixes various bugs, and then enables it by default in configure. It also makes the PRMs use the loadable modules, adding new new sub-RPMs for each module. We can now finally install minimal libvirt binaries for each hypervisor. ie yum install libvirt-kvm will not pull in Xen libraries! -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 00/10] Enable loadable modules for libvirtd
On 04/02/2012 01:57 PM, Daniel P. Berrange wrote: For a long timer we've had the ability to build each libvirt driver as a loadable module. We have never used this by default and as a result it constantly bit-rots. This series fixes various bugs, and then enables it by default in configure. It also makes the PRMs use the loadable modules, adding new new sub-RPMs for each module. We can now finally install minimal libvirt binaries for each hypervisor. ie yum install libvirt-kvm will not pull in Xen libraries! Awesome. It's too late to justify this in 0.9.11, but I hope to review this in time for 0.9.12. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
