Red Hat Bugzilla – Bug 1017646
RFE: block resize could check if the new size is big enough for guest's data
Last modified: 2017-10-16 09:30:55 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)
Steps to Reproduce:
1.boot a guest with virtio-blk-pci(system disk is 60G):
-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 \
-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
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.
after step 5,qemu-kvm should handle this kind of improper value,rather than guest crash.
both scsi and block can hit this issue
Is this a windows specific issue? Does it happen with rhel guest as well?
(In reply to Qunfang Zhang from comment #2)
> Hi, Jinli
> Is this a windows specific issue? Does it happen with rhel guest as well?
retest with rhel guest,guest will kenel panic after block_resize.
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.
(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.
So you have a 60 GB file system, truncate it to 16 GB and things break? Big
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
This has nothing to do with RHEV as rhev doesn't even support shrinking of a disk.
I will test if vol-resize can cover this.
Move to consideration for 7.4