Fix included in qemu-kvm-rhev-2.6.0-28.el7_3.7

According to https://bugzilla.redhat.com/show_bug.cgi?id=1397870#c34 and https://bugzilla.redhat.com/show_bug.cgi?id=1397870#c35,
Commit 9a93d47ddba5f86d36cbdf884d86e2fa6f5542ae has fixed this issue.
Checked on qemu-kvm-rhev-2.6.0-28.el7_3.7:

# cat kvm-block-check-full-backing-filename-when-searching-pro.patch 
From 33122cde2f27e8a6ff8c3e791152c62948dd24dd Mon Sep 17 00:00:00 2001
From: Jeffrey Cody <jcody>
Date: Tue, 21 Feb 2017 16:29:56 +0100
Subject: [PATCH 1/4] block: check full backing filename when searching
 protocol filenames

RH-Author: Jeffrey Cody <jcody>
Message-id: <9cfa02a61bc34480a6f58532ed92eb851db91eeb.1487694132.git.jcody>
Patchwork-id: 73958
O-Subject: [RHEV-7.3.z qemu-kvm-rhev 1/3] block: check full backing filename when searching protocol filenames
Bugzilla: 1425125
RH-Acked-by: John Snow <jsnow>
RH-Acked-by: Laurent Vivier <lvivier>
RH-Acked-by: Stefan Hajnoczi <stefanha>

In bdrv_find_backing_image(), if we are searching an image for a backing
file that contains a protocol, we currently only compare unmodified
paths.

However, some management software will change the backing filename to be
a relative filename in a path.  QEMU is able to handle this fine,
because internally it will use path_combine to put together the full
protocol URI.

However, this can lead to an inability to match an image during a QAPI
command that needs to use bdrv_find_backing_image() to find the image,
when it is searched by the full URI.

When searching for a protocol filename, if the straight comparison
fails, this patch will also compare against the full backing filename to
see if that is a match.

Signed-off-by: Jeff Cody <jcody>
Message-id: c2d025adca8a2b665189e6f4cf080f44126d0b6b.1485392617.git.jcody
Reviewed-by: Max Reitz <mreitz>
Signed-off-by: Max Reitz <mreitz>
(cherry picked from commit 418661e0324c1c419552cf24bd4447292e884bdd)
Signed-off-by: Miroslav Rezanina <mrezanin>
---
 block.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/block.c b/block.c
index 75afea5..de52900 100644
--- a/block.c
+++ b/block.c
@@ -3126,6 +3126,7 @@ BlockDriverState *bdrv_find_backing_image(BlockDriverState *bs,
     int is_protocol = 0;
     BlockDriverState *curr_bs = NULL;
     BlockDriverState *retval = NULL;
+    Error *local_error = NULL;
 
     if (!bs || !bs->drv || !backing_file) {
         return NULL;
@@ -3146,6 +3147,18 @@ BlockDriverState *bdrv_find_backing_image(BlockDriverState *bs,
                 retval = curr_bs->backing->bs;
                 break;
             }
+            /* Also check against the full backing filename for the image */
+            bdrv_get_full_backing_filename(curr_bs, backing_file_full, PATH_MAX,
+                                           &local_error);
+            if (local_error == NULL) {
+                if (strcmp(backing_file, backing_file_full) == 0) {
+                    retval = curr_bs->backing->bs;
+                    break;
+                }
+            } else {
+                error_free(local_error);
+                local_error = NULL;
+            }
         } else {
             /* If not an absolute filename path, make it relative to the current
              * image's filename path */
-- 
1.8.3.1

So move this bz to 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://access.redhat.com/errata/RHSA-2017:0985