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