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
Hi, Jinli Is this a windows specific issue? Does it happen with rhel guest as well? Thanks, Qunfang
(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.
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 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.
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
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.