Bug 1017646 - RFE: block resize could check if the new size is big enough for guest's data
RFE: block resize could check if the new size is big enough for guest's data
Status: ASSIGNED
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt (Show other bugs)
7.0
Unspecified Unspecified
high Severity high
: rc
: 7.1
Assigned To: John Ferlan
Han Han
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-10 05:38 EDT by lijin
Modified: 2017-10-16 09:30 EDT (History)
18 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-10-15 04:04:32 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description lijin 2013-10-10 05:38:21 EDT
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 01:17:34 EDT
Hi, Jinli

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

Thanks,
Qunfang
Comment 3 lijin 2013-10-11 22:36:47 EDT
(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-11 22:39:30 EDT
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 03:10:59 EDT
(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 04:04:32 EDT
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 04:21:22 EDT
This has nothing to do with RHEV as rhev doesn't even support shrinking of a disk.
Comment 9 Shanzhi Yu 2013-11-22 04:38:23 EST
I will test if vol-resize can cover this.
Comment 12 John Ferlan 2016-06-22 11:01:59 EDT
Move to consideration for 7.4

Note You need to log in before you can comment on or make changes to this bug.