Description of problem: Merge 2 bitmaps failed when 1 bitmap resides on the top volume and the other on the base volume. Merging those bitmaps failed only when trying to merge the top bitmap to the base bitmap Version-Release number of selected component (if applicable): qemu-kvm-4.2.0-25.module+el8.2.1+6985+9fd9d514.x86_64 How reproducible: 100% Steps to Reproduce: $ qemu-img create -f qcow2 base.qcow2 1024m $ qemu-img create -f qcow2 -b base.qcow2 top.qcow2 Add bitmaps: $ qemu-img bitmap --add --enable base.qcow2 base_bitmap $ qemu-img bitmap --add --enable top.qcow2 top_bitmap Trying to merge top.qcow2 top_bitmap into base.qcow2 base_bitmap $ qemu-img bitmap --merge top_bitmap base.qcow2 base_bitmap -f qcow2 -F qcow2 -b top.qcow2 Actual results: Error is thrown - qemu-img: Could not open 'top.qcow2': Could not open backing file: Failed to get shared "write" lock Is another process using the image [base.qcow2]? Expected results: Merge should succeed Additional info:
This bug is blocking us from fixing bug 1861667. If 'qemu-img --merge' cannot work on bitmap merge from top volume to base volume we cannot merge bitmaps on merging external snapshot with bitmaps manually.
Tested it with qemu-5.1, also hit this issue. Versions: kernel-4.18.0-234.el8.x86_64 qemu-kvm-5.1.0-5.module+el8.3.0+7975+b80d25f1 Steps: 1. create an image and snapshot # qemu-img create -f qcow2 base.qcow2 1024M # qemu-img create -f qcow2 -b base.qcow2 top.qcow2 2. add bitmaps # qemu-img bitmap --add --enable base.qcow2 base_bitmap # qemu-img bitmap --add --enable top.qcow2 top_bitmap 3. merge bitmap # qemu-img bitmap -f qcow2 base.qcow2 -F qcow2 -b top.qcow2 --merge top_bitmap base_bitmap qemu-img: Could not open 'top.qcow2': Could not open backing file: Failed to get shared "write" lock Is another process using the image [base.qcow2]? Hi Eric, Please help check if the scenario has been supported already and if the usage is correct? According to commit 3b51ab4bf0f49a01cc2db7b954e0669e081719b5, it should be supported in qemu-5.1. I'm not sure if rhel.8.2.1-av support it? And I have confirmed with aliang, it works well when merging external bitmaps with QMP commands. Many thanks.
Patch posted upstream already: https://lists.nongnu.org/archive/html/qemu-devel/2020-09/msg03412.html Please let us know if an 8.2.1.z-stream will also be requested or if 8.3.0 will be sufficient.
Upstream patch posted: https://lists.gnu.org/archive/html/qemu-devel/2020-09/msg03412.html
(In reply to John Ferlan from comment #3) > Patch posted upstream already: > https://lists.nongnu.org/archive/html/qemu-devel/2020-09/msg03412.html > > Please let us know if an 8.2.1.z-stream will also be requested or if 8.3.0 > will be sufficient. Code depending on this will be released in RHV 4.4.3, requiring RHEL 8.3.0, so I don't think we need a backport for 8.2.1. But having this in 8.3.0 will be nice. This is required when libvirt will switch incremental backup to fully supported status.
v2: https://lists.nongnu.org/archive/html/qemu-devel/2020-09/msg05048.html
(In reply to Xueqiang Wei from comment #2) > Tested it with qemu-5.1, also hit this issue. > > > Versions: > kernel-4.18.0-234.el8.x86_64 > qemu-kvm-5.1.0-5.module+el8.3.0+7975+b80d25f1 This build lacks the backport, hence... > > > Steps: > 1. create an image and snapshot > # qemu-img create -f qcow2 base.qcow2 1024M > # qemu-img create -f qcow2 -b base.qcow2 top.qcow2 > > 2. add bitmaps > # qemu-img bitmap --add --enable base.qcow2 base_bitmap > # qemu-img bitmap --add --enable top.qcow2 top_bitmap > > 3. merge bitmap > # qemu-img bitmap -f qcow2 base.qcow2 -F qcow2 -b top.qcow2 --merge > top_bitmap base_bitmap > qemu-img: Could not open 'top.qcow2': Could not open backing file: Failed to > get shared "write" lock > Is another process using the image [base.qcow2]? ...this failure indeed correctly demonstrates the bug. With the patch in, the merge will succeed. > > Hi Eric, > > Please help check if the scenario has been supported already and if the > usage is correct? > > According to commit 3b51ab4bf0f49a01cc2db7b954e0669e081719b5, it should be > supported in qemu-5.1. I'm not sure if rhel.8.2.1-av support it? The patch did not make it into qemu-5.1; it is being backported for 8.3.0. > > > And I have confirmed with aliang, it works well when merging external > bitmaps with QMP commands. Many thanks.
Tested with qemu-kvm-5.1.0-10.module+el8.3.0+8254+568ca30d, not hit this issue. And tested with --add, --remove, --clear, --enable and --disable, also not hit new issue. So set status to VERIFIED. Versions: kernel-4.18.0-240.el8.x86_64 qemu-kvm-5.1.0-10.module+el8.3.0+8254+568ca30d Steps: 1. create an image and snapshot # qemu-img create -f qcow2 base.qcow2 1024M # qemu-img create -f qcow2 -F qcow2 -b base.qcow2 top.qcow2 2. add bitmaps # qemu-img bitmap --add --enable base.qcow2 base_bitmap # qemu-img bitmap --add --enable top.qcow2 top_bitmap 3. merge bitmap # qemu-img bitmap -f qcow2 base.qcow2 -F qcow2 -b top.qcow2 --merge top_bitmap base_bitmap # echo $? 0 # qemu-img info base.qcow2 image: base.qcow2 file format: qcow2 virtual size: 1 GiB (1073741824 bytes) disk size: 452 KiB cluster_size: 65536 Format specific information: compat: 1.1 compression type: zlib lazy refcounts: false bitmaps: [0]: flags: [0]: auto name: base_bitmap granularity: 65536 refcount bits: 16 corrupt: false # qemu-img info top.qcow2 image: top.qcow2 file format: qcow2 virtual size: 1 GiB (1073741824 bytes) disk size: 324 KiB cluster_size: 65536 backing file: base.qcow2 backing file format: qcow2 Format specific information: compat: 1.1 compression type: zlib lazy refcounts: false bitmaps: [0]: flags: [0]: auto name: top_bitmap granularity: 65536 refcount bits: 16 corrupt: false
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 (virt:8.3 bug fix and enhancement update), 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/RHBA-2020:5137