[libvirt] [PATCH 00/10] Enable loadable modules for libvirtd

[Eric Blake]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 620 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20120403/6bd68b71/attachment-0001.sig>