[libvirt] [PATCH] spec: Remove qemu-img dependency from storage driver

Jiri Denemark jdenemar at redhat.com
Thu Dec 4 13:42:31 UTC 2014


On Wed, Dec 03, 2014 at 15:58:45 +0000, Daniel Berrange wrote:
> On Wed, Dec 03, 2014 at 04:52:25PM +0100, Jiri Denemark wrote:
> > Both qemu-img and its stripped down version qcow-create are searched for
> > dynamically with virFindFileInPath, functions using them report errors
> > when the required binary is not present, and we don't compile in a fixed
> > path detected by configure anymore. So I don't see a reason for keeping
> > the dependencies for our storage driver. Moreover, it's weired when the
> > dependencies (of the storage driver) change depending on wheter a
> > particular hypervisor driver (xen/qemu) is enabled or not.
> > 
> > Signed-off-by: Jiri Denemark <jdenemar at redhat.com>
> > ---
> >  libvirt.spec.in | 18 ------------------
> >  1 file changed, 18 deletions(-)
> 
> Even if using the Xen hypervisor, you can use the qemu-img binary
> for creating volumes. Since the qemu-img binary is in a separate
> RPM from the main QEMU emulator binaries, it makes sense to depend
> on qemu-img if we're enabling QEMU support in libvirt. Similarly the
> LXC driver can make use of qemu-img for creating images that are then
> used via qemu-nbd.
> 
> So I think our current Requires deps are actually correct here - they
> ensure that the qemu-img binary is always pulled into the host, no
> matter what daemon-driver-XXX is installed.

But it still feels wrong. A choice of what hypervisor driver is enabled
should not influence dependencies of a storage driver. If we want the
storage driver to depend on qemu-img, I think the dependency should be
enabled by a separate switch, so that one can enable qemu-img support
without enabling qemu driver. Or am I just over-engineering it based on
my confusion why storage deps change depending on enabled HV drivers?

Jirka




More information about the libvir-list mailing list