Bug 999476

Summary: Guest OS can not boot from snapshot image which is smaller than its base image
Product: Red Hat Enterprise Linux 7 Reporter: Jun Li <juli>
Component: qemu-kvmAssignee: Jeff Cody <jcody>
Status: CLOSED NOTABUG QA Contact: Virtualization Bugs <virt-bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.0CC: acathrow, hhuang, juzhang, michen, qiguo, sluo, virt-maint, xfu
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-09-06 18:34:18 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Jun Li 2013-08-21 11:36:18 UTC
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.

Comment 2 Sibiao Luo 2013-08-22 01:55:37 UTC
(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.

Comment 3 Jun Li 2013-08-22 02:33:55 UTC
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

Comment 4 Jeff Cody 2013-09-06 18:20:00 UTC
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.

Comment 5 Jun Li 2013-09-09 02:58:33 UTC
(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.