[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

Attachment: signature.asc
Description: OpenPGP digital signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]