Hide Forgot
Description of problem: Create a snapshot based on the qcow2/qcow2_v3 image which is pre-installed. When this snapshot is smaller than base image, guest os can not boot with this snapshot. Version-Release number of selected component (if applicable): qemu-kvm-1.5.2-4.el7.x86_64 qemu-img-1.5.2-4.el7.x86_64 3.10.0-9.el7.x86_64 How reproducible: 100% Steps to Reproduce: 1.Create snapshot image, which is smaller than the base. The base image info: # qemu-img info /home/win2012-64.qcow3 image: /home/win2012-64.qcow3 file format: qcow2 virtual size: 30G (32212254720 bytes) disk size: 8.2G cluster_size: 65536 # qemu-img create -f qcow2 -o compat=1.1 -b win2012-64.qcow3 sp1.qcow2_v3 1G 2.Boot with snapshot image: #<qemu-kvm cli> ... -drive file=/home/sp1.qcow2_v3,if=none,id=block-virtio,cache=none,werror=stop,rerror=stop,format=raw -device virtio-blk-pci,bus=pci.0,addr=0x8,drive=block-virtio,id=block-virtio,bootindex=1 ... Actual results: Guest os can not boot successfully, and check the info of this snapshot: # qemu-img info sp1.qcow2_v3-1 image: sp1.qcow2_v3-1 file format: qcow2 virtual size: 1.0G (1073741824 bytes) disk size: 520K cluster_size: 65536 backing file: win2012-64.qcow3 The "disk size" can not change during booting, but when I test with the snapshot image that same size or bigger than the base, the "disk size" will increase till the guest os boot successfully. Expected results: The guest os can boot successfully with a smaller-size snapshot image. Additional info: Both windows and rhel guest hit this issue.
(In reply to Jun Li from comment #0) > Description of problem: > Create a snapshot based on the qcow2/qcow2_v3 image which is pre-installed. > When this snapshot is smaller than base image, guest os can not boot with > this snapshot. > > Version-Release number of selected component (if applicable): > qemu-kvm-1.5.2-4.el7.x86_64 > qemu-img-1.5.2-4.el7.x86_64 > 3.10.0-9.el7.x86_64 > > How reproducible: > 100% > > Steps to Reproduce: > 1.Create snapshot image, which is smaller than the base. > > The base image info: > # qemu-img info /home/win2012-64.qcow3 > image: /home/win2012-64.qcow3 > file format: qcow2 > virtual size: 30G (32212254720 bytes) > disk size: 8.2G > cluster_size: 65536 > > # qemu-img create -f qcow2 -o compat=1.1 -b win2012-64.qcow3 sp1.qcow2_v3 1G > > 2.Boot with snapshot image: > #<qemu-kvm cli> ... -drive > file=/home/sp1.qcow2_v3,if=none,id=block-virtio,cache=none,werror=stop, > rerror=stop,format=raw -device > virtio-blk-pci,bus=pci.0,addr=0x8,drive=block-virtio,id=block-virtio, > bootindex=1 ... Why use format=raw in cli ? as you create the disk is qcowX format, it's sure can't boot up i think, could you help double-check it, maybe not a bug. > Actual results: > Guest os can not boot successfully, and check the info of this snapshot: > # qemu-img info sp1.qcow2_v3-1 > image: sp1.qcow2_v3-1 > file format: qcow2 > virtual size: 1.0G (1073741824 bytes) > disk size: 520K > cluster_size: 65536 > backing file: win2012-64.qcow3 > > The "disk size" can not change during booting, but when I test with the > snapshot image that same size or bigger than the base, the "disk size" will > increase till the guest os boot successfully. > > Expected results: > The guest os can boot successfully with a smaller-size snapshot image. > > Additional info: > Both windows and rhel guest hit this issue.
Re-tested this issue with correctly command line(raw ->qcow2), still hit this issue. -drive file=/home/sp1.qcow2_v3,if=none,id=block-virtio,cache=none,werror=stop,rerror=stop,format=qcow2 -device virtio-blk-pci,bus=pci.0,addr=0x8,drive=block-virtio,id=block-virtio,bootindex=1
I don't believe this is a valid bug. If the base image is larger, and has an OS pre-installed, then creating a snapshot like this with an image with a smaller virtual size on top is going to effectively truncate (from QEMU's perspective) the image size in the BDS chain. In this case, QEMU is going to see a virtual disk sized at 1GB, and reads beyond 1GB will return 0.
(In reply to Jeff Cody from comment #4) > I don't believe this is a valid bug. > > If the base image is larger, and has an OS pre-installed, then creating a > snapshot like this with an image with a smaller virtual size on top is going > to effectively truncate (from QEMU's perspective) the image size in the BDS > chain. In this case, QEMU is going to see a virtual disk sized at 1GB, and > reads beyond 1GB will return 0. Thank you for your detailed explanations. I thought Snapshot can not be created successfully if we specify that snapshot < base. Or maybe we should prohibit specify the size of snapshot when we create it in command line in the future. Anyway, it's ok close this bug on QE side and thx again for your detailed explanations.