Description of problem:
If a qcow2 file is opened with an explicit backing override (such as for fd passing, -drive file=...,backing.file.filename=/dev/fdset/2), then operations on that file that rewrite the metadata will change the backing file name to the override, instead of the desired action of leaving it untouched.
See also: https://lists.gnu.org/archive/html/qemu-devel/2015-04/msg00280.html
Version-Release number of selected component (if applicable):
still present in upstream qemu.git as of commit 2.3-rc2
Steps to Reproduce:
1. see the referenced thread; that used HMP, but I suspect that a scenario can be generated using only QMP
the qcow2 file backing name is rewritten to a bogus /dev/fdset reference, losing information if one does not remember which file was assigned to that fdset
when updating qcow2 metadata, the original backing name should be preserved even when the backing file was opened via fd override
libvirt hopes to start using fdset overrides for additional security on NFS, so this needs to work correctly
see also bug 1208587
This was fixed in 2.3.0-rc3, so we got the fix with the recent rebase.
I confirmed that RHEL qemu-kvm and RHEL 7.1 qemu-kvm-rhev are not affected.
[root@dhcp-11-50 qemu-kvm-rhev7]# git log --oneline v2.2.0..v2.3.0-rc3 block/qcow2.c VERSION
b8df920 Update version for v2.3.0-rc3 release
e4603fe qcow2: Fix header update with overridden backing file
^ the commit message from Kevin which fixed this bug
f2155a0 Update version for v2.3.0-rc2 release
054903a Update version for v2.3.0-rc1 release
cd232ac Update version for v2.3.0-rc0 release
87b86e7 qcow2: fix the macro QCOW_MAX_L1_SIZE's use
06d05fa qcow2: Allow creation with refcount order != 4
8a17b83 qcow2: Use symbolic macros in qcow2_amend_options
bd4b167 qcow2: refcount_order parameter for qcow2_create2
b72faf9 qcow2: Open images with refcount order != 4
0709c5a qcow2: Add refcount_bits to format-specific info
346a53d qcow2: Add two new fields to BDRVQcowState
f43e47d QemuOpts: Drop qemu_opt_set(), rename qemu_opt_set_err(), fix use
39101f2 QemuOpts: Convert qemu_opt_set_number() to Error, fix its use
c0191e7 block: Remove "growable" from BDS
e729fa6 block: fix off-by-one error in qcow and qcow2
9a29e18 block: update string sizes for filename,backing_file,exact_filename
^ the previous commit that touched backing file, I am guessing this is the one needs a fix(correct me if I am wrong)
6a69b96 qcow2: Respect bdrv_truncate() error
3b5e14c qcow2: Flushing the caches in qcow2_close may fail
ef81043 block: Omit bdrv_find_format for essential drivers
5f535a9 block: Make essential BlockDriver objects public
2ebafc8 qcow2: Fix header extension size check
7fb8da2 Open 2.3 development tree
^ and seems both the above 2 commits are merged in version 2.3 window,
so this bug is not exist on any internal qemu binary.
internal latest 2.2.0-8 fellowed by 2.3.0-1, and not any rc of 2.3.
1) could you pls have a look whether above comment correct ?
2) I've tried the test case introduced along with this bug fix, it's fine on below internel binaries:
[root@dhcp-11-50 qemu-iotests]# ./check -qcow2 130
QEMU -- /home/xwei/git-repos/qemu-kvm-rhev7/tests/qemu-iotests/../../x86_64-softmmu/qemu-system-x86_64
QEMU_IMG -- /usr/bin/qemu-img
QEMU_IO -- /home/xwei/git-repos/qemu-kvm-rhev7/tests/qemu-iotests/../../qemu-io
QEMU_NBD -- /home/xwei/git-repos/qemu-kvm-rhev7/tests/qemu-iotests/../../qemu-nbd
IMGFMT -- qcow2 (compat=1.1)
IMGPROTO -- file
PLATFORM -- Linux/x86_64 dhcp-11-50 3.10.0-276.el7.x86_64
TEST_DIR -- /home/xwei/git-repos/qemu-kvm-rhev7/tests/qemu-iotests/scratch
SOCKET_SCM_HELPER -- /home/xwei/git-repos/qemu-kvm-rhev7/tests/qemu-iotests/socket_scm_helper
130 2s ...
Passed all 1 tests
is 2) sufficient to verify this bug ?
(In reply to Xiaoqing Wei from comment #6)
> ^ and seems both the above 2 commits are merged in version 2.3 window,
> so this bug is not exist on any internal qemu binary.
> internal latest 2.2.0-8 fellowed by 2.3.0-1, and not any rc of 2.3.
> 1) could you pls have a look whether above comment correct ?
This looks correct to me.
> 2) I've tried the test case introduced along with this bug fix, it's fine on
> below internel binaries:
> is 2) sufficient to verify this bug ?
Yes, it is. Thanks for testing.
(In reply to Kevin Wolf from comment #7)
> > is 2) sufficient to verify this bug ?
> Yes, it is. Thanks for testing.
Thanks for confirm,
Moving 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.