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 eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org