Hide Forgot
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 How reproducible: 100% Steps to Reproduce: 1. see the referenced thread; that used HMP, but I suspect that a scenario can be generated using only QMP 2. 3. Actual results: 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 Expected results: when updating qcow2 metadata, the original backing name should be preserved even when the backing file was opened via fd override Additional info: 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. Kevin, 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: qemu-kvm-rhev-2.2.0-8 qemu-kvm-rhev-2.3.0-1 qemu-kvm-rhev-2.3.0-9 [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 ? Thanks, Xiaoqing.
(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. > > Kevin, > > 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: > qemu-kvm-rhev-2.2.0-8 > qemu-kvm-rhev-2.3.0-1 > qemu-kvm-rhev-2.3.0-9 > > 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. https://rhn.redhat.com/errata/RHBA-2015-2546.html