+++ This bug was initially created as a clone of Bug #1727347 +++ Description of problem: The qcow2 spec requires that any v3 file with internal snapshots must use at least 16 bytes of extra data per snapshot entry, in order to include the virtual disk size of the internal snapshot. However, when converting a v2 file created by older qemu (such as RHEL 6) into a v3 file, the existing snapshot headers are not expanded into the correct v3 format. True, RHEL tends to frown on internal snapshots (and prefers the use of external), but creating an image that violates the spec, and one that 'qemu-img check' fails to diagnose as violating the spec, is not good for interoperability. Version-Release number of selected component (if applicable): qemu-kvm-4.0.0-6.module+el8.1.0+3736+a2aefea3 How reproducible: 100% Steps to Reproduce: 1. Create a v2 file with internal snapshot. On RHEL6: $ qemu-img create -f qcow2 file 1m $ qemu-img snapshot -c s1 file 2. Check that the internal snapshot header uses the smaller size: $ od -Ax -j64 -N8 -tx1 file # Learn the offset for the next command $ offset=$((0x50000+36)) $ od -Ax -j$offset -N 4 -tx1 file 3. Upgrade it to v3. On RHEL8: $ qemu-img amend -o compat=1.1 file 4. Check the internal snapshot header size: $ od -Ax -j64 -N8 -tx1 file # Learn the offset for the next command $ offset=$((0x50000+36)) $ od -Ax -j$offset -N 4 -tx1 file 5. Contrast with an image created natively in v3. On RHEL8: $ qemu-img create -f qcow2 file2 1m $ qemu-img snapshot -c s1 file2 $ od -Ax -j64 -N8 -tx1 file2 # Learn the offset for the next command $ offset=$((0x50000+36)) $ od -Ax -j$offset -N 4 -tx1 file2 Actual results: 2. extra size is 0 4. extra size is still 0 5. extra size is 16 Expected results: 4. extra size should change from 0 to 16 Additional info: qemu-img amend should be taught to rewrite the internal snapshots table to ensure that things get padded out. Having the disk size at the time of each snapshot is a prerequisite to being able to resize an image that contains internal snapshots (we forbid resize of v2 images with internal snapshots because otherwise you may lack the size to switch back to on reverting to that snapshot, but this is a pointless restriction for v3 images).
Verified this bug as below. Tested with: qemu-kvm-4.2.0-1.module+el8.2.0+4793+b09dd2fb kernel-4.18.0-153.el8.x86_64 Steps: 1. Create a v2 file with internal snapshot. On RHEL6: # rpm -qa | grep qemu-img qemu-img-rhev-0.12.1.2-2.491.el6_8.3.x86_64 # qemu-img create -f qcow2 test_v2.qcow2 1m # qemu-img snapshot -c s1 test_v2.qcow2 # qemu-img info test_v2.qcow2 image: test_v2.qcow2 file format: qcow2 virtual size: 1.0M (1048576 bytes) disk size: 204K cluster_size: 65536 Snapshot list: ID TAG VM SIZE DATE VM CLOCK 1 s1 0 2019-11-29 01:42:23 00:00:00.000 2. Check that the internal snapshot header uses the smaller size: # od -Ax -j64 -N8 -tx1 test_v2.qcow2 000040 00 00 00 00 00 05 00 00 000048 # offset=$((0x50000+36)) # od -Ax -j$offset -N 4 -tx1 test_v2.qcow2 050024 00 00 00 00 ------------------------------------ The extra size is 0. 050028 3. Scp the image to RHEL8 host, and upgrade it to v3. # qemu-img --version qemu-img version 4.2.0 (qemu-kvm-4.2.0-1.module+el8.2.0+4793+b09dd2fb) # qemu-img amend -o compat=1.1 test_v2.qcow2 4. Check the internal snapshot header size: # od -Ax -j64 -N8 -tx1 test_v2.qcow2 000040 00 00 00 00 00 06 00 00 000048 # offset=$((0x60000+36)) # od -Ax -j$offset -N 4 -tx1 test_v2.qcow2 060024 00 00 00 10 -------------------------------------- The size is changed to 16. 060028
QEMU has been recently split into sub-components and as a one-time operation to avoid breakage of tools, we are setting the QEMU sub-component of this BZ to "General". Please review and change the sub-component if necessary the next time you review this BZ. Thanks
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/RHBA-2020:2017