Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

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-kvm	Assignee:	Jeff Cody <jcody>
Status:	CLOSED NOTABUG	QA Contact:	Virtualization Bugs <virt-bugs>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.0	CC:	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:
Embargoed:

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.