Red Hat Bugzilla – Bug 1425125
qemu fails to recognize gluster URIs in backing chain for block-commit operation
Last modified: 2017-04-18 02:07:12 EDT
This bug has been copied from bug #1397870 and has been proposed to be backported to 7.3 z-stream (EUS).
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@redhat.com> 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@redhat.com> Message-id: <9cfa02a61bc34480a6f58532ed92eb851db91eeb.1487694132.git.jcody@redhat.com> 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@redhat.com> RH-Acked-by: Laurent Vivier <lvivier@redhat.com> RH-Acked-by: Stefan Hajnoczi <stefanha@redhat.com> 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@redhat.com> Message-id: c2d025adca8a2b665189e6f4cf080f44126d0b6b.1485392617.git.jcody@redhat.com Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com> (cherry picked from commit 418661e0324c1c419552cf24bd4447292e884bdd) Signed-off-by: Miroslav Rezanina <mrezanin@redhat.com> --- 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