Bug 1017646

Summary:	RFE: block resize could check if the new size is big enough for guest's data
Product:	Red Hat Enterprise Linux Advanced Virtualization	Reporter:	lijin <lijin>
Component:	libvirt	Assignee:	Libvirt Maintainers <libvirt-maint>
Status:	CLOSED WONTFIX	QA Contact:	Meina Li <meili>
Severity:	high	Docs Contact:
Priority:	high
Version:	---	CC:	chayang, dyuan, jdenemar, jsuchane, juzhang, lijin, lmen, lpeer, mkenneth, mzhan, qzhang, rbalakri, srevivo, virt-maint, vrozenfe, xuzhang
Target Milestone:	pre-dev-freeze	Keywords:	FutureFeature
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-07-25 07:59:05 UTC	Type:	Feature Request
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description lijin 2013-10-10 09:38:21 UTC

Description of problem:
boot a guest with virtio-scsi/virtio-blk system disk,block_resize the system disk to an improper value(such as 16G,the original size is 60G),guest will bsod with F4 code,and the image can never boot up again,no dump file can be found even attach this image to other bootable guest.

Version-Release number of selected component (if applicable):
Red Hat Enterprise Linux Server release 6.4 (Santiago)
qemu-kvm-rhev-0.12.1.2-2.355.el6_4.9.x86_64
kernel-2.6.32-358.21.1.el6.x86_64
seabios-0.6.1.2-28.el6.x86_64
vgabios-0.6b-3.7.el6.noarch
virtio-win-prewhql-71

How reproducible:
100%

Steps to Reproduce:
1.boot a guest with virtio-blk-pci(system disk is 60G):
/usr/libexec/qemu-kvm   \
-drive file=win7-64-new.raw,if=none,cache=writethrough,media=disk,format=raw,id=drive-ide0-0-1 -device virtio-blk-pci,id=ide1,drive=drive-ide0-0-1,bootindex=1 \
-monitor stdio \
-usb -device usb-tablet,id=tablet1 \
-boot menu=on \
-chardev file,path=/root/console.log,id=serial1 \
-device isa-serial,chardev=serial1,id=s1 \
-cpu Penryn -M rhel6.4.0 \
-smp 2,cores=2,threads=1,sockets=1 -m 2G \
-enable-kvm \
-spice disable-ticketing,port=5900 -vga qxl \
-global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0 \

2.shrink volume in the guest,29.28G can be shrinked. 
3.block_resize system disk to 31G
4.block_resize system disk to 30G
5.block_resize system disk to 16G

Actual results:
1).after step 3,disk can be resize correctly;
2).after step 4,the disk became 30.72G,and sometimes qemu prompts "Input/output error (5)"
3).after step 5,the disk became 16G,and bsodafter a while guest bsod with F4 code,and this guest cannot boot up.

Expected results:
after step 5,qemu-kvm should handle this kind of improper value,rather than guest crash.

Additional info:
both scsi and block can hit this issue

Comment 2 Qunfang Zhang 2013-10-11 05:17:34 UTC

Hi, Jinli

Is this a windows specific issue? Does it happen with rhel guest as well?

Thanks,
Qunfang

Comment 3 lijin 2013-10-12 02:36:47 UTC

(In reply to Qunfang Zhang from comment #2)
> Hi, Jinli
> 
> Is this a windows specific issue? Does it happen with rhel guest as well?
> 
> Thanks,
> Qunfang

retest with rhel guest,guest will kenel panic after block_resize.

Comment 4 Mike Cao 2013-10-12 02:39:30 UTC

This bug is like RFE rather than a bug . We need to do some limitation in qemu-kvm side eg the shrinking size shouldn't larger than un-allocated space in the guest.

Comment 5 Vadim Rozenfeld 2013-10-12 07:10:59 UTC

(In reply to Mike Cao from comment #4)
> This bug is like RFE rather than a bug . We need to do some limitation in
> qemu-kvm side eg the shrinking size shouldn't larger than un-allocated space
> in the guest.

Right, we should be very careful when shrinking a volume, to prevent the situation when the new disk size is smaller than the guest OS thinks it is.

Comment 6 Kevin Wolf 2013-10-15 08:04:32 UTC

So you have a 60 GB file system, truncate it to 16 GB and things break? Big
surprise...

This behaviour is completely expected. It's also not something that qemu could
possibly warn against, because qemu doesn't know what data on the disk is
used and what can be safely dropped. It completely depends on the guest. If
anything, management tools could warn against it, probably in cooperation with
a guest agent.

If you want us to explore this, it's probably best to open a libvirt RFE for
RHEL 7.

Comment 7 Ayal Baron 2013-10-16 08:21:22 UTC

This has nothing to do with RHEV as rhev doesn't even support shrinking of a disk.

Comment 9 Shanzhi Yu 2013-11-22 09:38:23 UTC

I will test if vol-resize can cover this.

Comment 12 John Ferlan 2016-06-22 15:01:59 UTC

Move to consideration for 7.4

Comment 13 Jaroslav Suchanek 2019-07-25 07:59:05 UTC

Considering comment 6, low priority for several consecutive releases (first reported for rhel-6.5) and that this is actually technically hardly solvable I am closing this is WONTFIX.