qemu-img in EPEL overrides kvm-qemu-img in RHEL

Richard W.M. Jones rjones at redhat.com
Mon Mar 1 21:55:25 UTC 2010


In reply to:

https://bugzilla.redhat.com/show_bug.cgi?id=569616

The background is that both qemu and KVM upstreams build a tool called
/usr/bin/qemu-img.  In theory the qemu-img tool built is the same and
only one version of it would be needed.  In reality differences in
configuration of qemu or KVM (ie. block drivers) lead to different
capabilities.

For example, if qemu is configured with the (mostly broken) VMDK block
driver support, then qemu-img from the qemu package would also have
VMDK capabilities.  Whereas in RHEL KVM might decide not to compile in
VMDK support because it is somewhat limited & broken, so KVM's
qemu-img would not have this.  You can find out what qemu-img supports
by doing:

  [qemu from Rawhide]
  $ qemu-img --help | grep Supported
  Supported formats: cow qcow vdi vmdk cloop dmg bochs vpc vvfat qcow2 parallels nbd host_cdrom host_floppy host_device raw

  [qemu-img from EPEL 5]
  $ qemu-img --help | grep Supported
  Supported formats: nbd parallels qcow2 vvfat vpc bochs dmg cloop vmdk qcow cow host_device raw

  [kvm-qemu-img from RHEL 5.4]
  $ qemu-img --help | grep Supported
  Supported format: parallels qcow2 vvfat vpc bochs dmg cloop vmdk qcow cow host_device raw

  [qemu-img from qemu-kvm package, from a recent RHEL 6 beta -- I think
   the plan is to remove more of these drivers before RHEL 6 is released
   because some of them are broken and should be inflicted on paying
   customers]
  $ qemu-img --help | grep Supported
  Supported formats: cow qcow vdi vmdk cloop dmg bochs vpc vvfat qcow2 parallels nbd host_cdrom host_floppy host_device raw

Now it is my understanding that the plan is to build KVM's qemu-img as
a binary called /usr/bin/kvm-qemu-img.  I'm not sure if this will be
just in RHEL 6, or will be in RHEL 5 too, although it seems like it
might be too late for RHEL 5 because it would break binary
compatibility.  If KVM's qemu-img is built as kvm-qemu-img then there
should be no conflict.

I don't think in any case it's a good idea to block the whole of qemu
just for this.  However blocking just /usr/bin/qemu-img from EPEL may
be possible (on architectures where there is a conflict) if people are
prepared for the fact that KVM's qemu-img might have slightly fewer
features.

I hope the above is all correct -- it's not "official" advice from Red Hat.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://et.redhat.com/~rjones/libguestfs/
See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html




More information about the epel-devel-list mailing list