A simple reproducer is:

  $ qemu-img create -f qcow2 /tmp/test.qcow2 10M
  Formatting '/tmp/test.qcow2', fmt=qcow2 size=10485760 encryption=off cluster_size=65536 lazy_refcounts=off 
  $ guestfish add /tmp/test.qcow2 format:qcow2 discard:enable : run
  libguestfs: error: discard cannot be enabled on this drive: qemu < 1.6 cannot do discard on qcow2 files

In this case, qemu-kvm-1.5.3-86.el7.x86_64 is installed.  The error
would not happen with qemu-kvm-rhev, since the version number of
qemu-kvm-rhev is >= 1.6 in RHEL >= 7.1.

The error is caused by virt-sparsify requesting discard = "enable"
as a parameter of add_drive_opts.  Refer to the API documentation
here:

  http://libguestfs.org/guestfs.3.html#guestfs_add_drive_opts

The error only happens when the disk image format is qcow2.

What is supposed to happen is that libguestfs will use a qemu drive
parameter like:

  -drive file=...,discard=unmap

In qemu 1.5 (upstream) the qcow2 driver ignored the unmap parameter.
In qemu 1.6 (upstream) the qcow2 driver understood the unmap parameter
and can turn discard requests into host filesystem unmap operations.

The question is: does qemu-kvm-1.5.3-86.el7.x86_64 actually support qcow2
discards?  Which I'm still trying to determine ...

I finally was able to show that qemu-kvm-1.5.3-86.el7.x86_64
*does* support trimming of both raw and qcow2 files.  As this took
me a substantial amount of time, it's worth documenting it here:

(0) Ensure you have qemu-kvm-1.5.3 installed (not qemu-kvm-rhev).

(1) Patch out the bogus test in src/launch-direct.c and rebuild

diff --git a/src/launch-direct.c b/src/launch-direct.c
index fa3bb7a..c97e1a5 100644
--- a/src/launch-direct.c
+++ b/src/launch-direct.c
@@ -1434,7 +1434,7 @@ guestfs_int_discard_possible (guestfs_h *g, struct drive *
   /* qemu >= 1.6.  This was the first version that supported unmap on
    * qcow2 backing files.
    */
-  bool qemu16 = qemu_version >= 1006000;
+  /*  bool qemu16 = qemu_version >= 1006000;*/
 
   if (!qemu15)
     NOT_SUPPORTED (g, false,
@@ -1460,10 +1460,12 @@ guestfs_int_discard_possible (guestfs_h *g, struct drive
   else if (STREQ (drv->src.format, "raw"))
     /* OK */ ;
   else if (STREQ (drv->src.format, "qcow2")) {
+    /*
     if (!qemu16)
       NOT_SUPPORTED (g, false,
                      _("discard cannot be enabled on this drive: "
                        "qemu < 1.6 cannot do discard on qcow2 files"));
+    */
   }
   else {
     /* It's possible in future other formats will support discard, but

(2) Copy tests/discard/*.pl to /tmp.  *NB* These tests do not work on NFS.

(3) Run the tests like this:

$ ~/d/libguestfs-rhel-7.2/run ./test-blkdiscard.pl
$ ~/d/libguestfs-rhel-7.2/run ./test-discard.pl
$ ~/d/libguestfs-rhel-7.2/run ./test-fstrim.pl

and observe the output.  This shows that *raw* format files can be unmapped.

(4) Edit the '$format = ...' line in each test to "qcow2".

(5) Run the tests again as above.  This shows that *qcow2* format files
can be unmapped.

Since this error message turns out to be bogus, we should remove it
from RHEL 7, hence I am dev-ack-ing this bug.

(In reply to Richard W.M. Jones from comment #2)
> (2) Copy tests/discard/*.pl to /tmp.  *NB* These tests do not work on NFS.

Apparently the NFS problem will be fixed in 7.2 (bug 1079385).

Verified with the packages:
libguestfs-1.28.1-1.52.el7.x86_64
qemu-kvm-1.5.3-102.el7.x86_64

Verify steps:
1. # qemu-img create -f qcow2 /tmp/test.qcow2 10M
Formatting '/tmp/test.qcow2', fmt=qcow2 size=10485760 encryption=off cluster_size=65536 lazy_refcounts=off

2. # guestfish add /tmp/test.qcow2 format:qcow2 discard:enable : run -x -v
libguestfs: trace: set_verbose true
libguestfs: trace: set_verbose = 0
libguestfs: trace: set_pgroup true
libguestfs: trace: set_pgroup = 0
libguestfs: trace: add_drive "/tmp/test.qcow2" "format:qcow2" "discard:enable"
libguestfs: trace: add_drive = 0
libguestfs: trace: launch
libguestfs: trace: get_tmpdir
libguestfs: trace: get_tmpdir = "/tmp"
libguestfs: trace: version
libguestfs: trace: version = <struct guestfs_version *>
libguestfs: trace: get_backend
libguestfs: trace: get_backend = "libvirt"
libguestfs: launch: program=guestfish
...
...
verbose daemon enabled
linux command line: panic=1 console=ttyS0 udevtimeout=6000 udev.event-timeout=6000 no_timer_check acpi=off printk.time=1 cgroup_disable=memory root=/dev/sdb selinux=0 guestfs_verbose=1 TERM=xterm-256color

trying to open virtio-serial channel '/dev/virtio-ports/org.libguestfs.channel.0'
udevadm --debug settle
calling: settle
libguestfs: recv_from_daemon: received GUESTFS_LAUNCH_FLAG
libguestfs: [03399ms] appliance is up
libguestfs: trace: launch = 0
libguestfs: trace: shutdown
libguestfs: trace: internal_autosync
guestfsd: main_loop: new request, len 0x28
umount-all: /proc/mounts: fsname=rootfs dir=/ type=rootfs opts=rw freq=0 passno=0
umount-all: /proc/mounts: fsname=proc dir=/proc type=proc opts=rw,relatime freq=0 passno=0
umount-all: /proc/mounts: fsname=/dev/root dir=/ type=ext2 opts=rw,noatime freq=0 passno=0
umount-all: /proc/mounts: fsname=/proc dir=/proc type=proc opts=rw,relatime freq=0 passno=0
umount-all: /proc/mounts: fsname=/sys dir=/sys type=sysfs opts=rw,relatime freq=0 passno=0
umount-all: /proc/mounts: fsname=tmpfs dir=/run type=tmpfs opts=rw,nosuid,relatime,size=97716k,mode=755 freq=0 passno=0
umount-all: /proc/mounts: fsname=/dev dir=/dev type=devtmpfs opts=rw,relatime,size=241840k,nr_inodes=60460,mode=755 freq=0 passno=0
fsync /dev/sda
libguestfs: trace: internal_autosync = 0
libguestfs: calling virDomainDestroy "guestfs-bsg220q5cfq3uncw" flags=VIR_DOMAIN_DESTROY_GRACEFUL
libguestfs: trace: shutdown = 0
libguestfs: trace: close
libguestfs: closing guestfs handle 0x7fddff73b470 (state 0)
libguestfs: command: run: rm
libguestfs: command: run: \ -rf /tmp/libguestfsOindop

No errors pop up. So verified.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-2183.html