Description of problem: Using the procedure described below I used virt-resize to increase the expand a windows virtual disk, but the Vrtual Machine is not booting Version-Release number of selected component (if applicable): fedora-release-14-1.noarch libguestfs-1.8.1-1.fc14.x86_64 libvirt-cim-0.5.8-2.fc13.x86_64 kernel-2.6.35.10-74.fc14.x86_64 libguestfs-tools-1.8.1-1.fc14.x86_64 libvirt-0.8.3-2.fc14.x86_64 libvirt-devel-0.8.3-2.fc14.x86_64 libvirt-client-0.8.3-2.fc14.x86_64 libvirt-python-0.8.3-2.fc14.x86_64 libguestfs-tools-c-1.8.1-1.fc14.x86_64 How reproducible: Always Steps to Reproduce: 1. Shut down the VM: # virsh list --all | grep WinXP - WinXP shut off 2. Locate the disk source: # virsh dumpxml WinXP | xpath /domain/devices/disk/source Found 1 nodes: -- NODE -- <source file="/var/lib/libvirt/images/WinXP.img" /> 3. Check the filesystems inside that disk image: # virt-filesystems --long --parts --blkdevs -h -a /var/lib/libvirt/images/WinXP.img Name Type Size Parent /dev/sda1 partition 8.0G /dev/sda /dev/sda device 8.0G - 4. Create a new disk image bigger than original: # virsh vol-create-as default WinXPBig.img 15G Vol WinXPBig.img created 5. Resize the new image expanding the partition: # virt-resize --expand /dev/sda1 WinXP.img WinXPBig.img Summary of changes: /dev/sda1: partition will be resized from 8.0G to 15.0G /dev/sda1: content will be expanded using the 'ntfsresize' method Copying /dev/sda1 ... [############################################################################]----] Expanding /dev/sda1 using the 'ntfsresize' method 6. Edit the VM XML configuration file to boot from the new disk: # virsh edit WinXP Domain WinXP XML configuration edited. # virsh dumpxml WinXP | xpath /domain/devices/disk/source Found 1 nodes: -- NODE -- <source file="/var/lib/libvirt/images/WinXPBig.img" /> 7. Boot the new VM Actual results: Not bootable Windows VM, after starting the VM it get stucked with the message "Booting from Hard Disk..." Expected results: Bootable Windows VM Additional info:
Javier, Thanks for the report. Unfortunately Rich is out for a few weeks, so there's unlikely to be any movement on this soon.
It looks like we've clobbered the boot loader. Can you try again, adding the --debug option so we get to see everything that virt-resize is really doing?
Also please try with the latest virt-resize from libguestfs 1.9.18. It has been rewritten, and it no longer moves the first partition which should make it less likely to clobber the bootloader.
Hi Richard, Unfortunately I can not reproduce the issue any more since I do not have the necessary files. Sorry about it. Regards.
OK, well let's leave this bug open for a while in case other people experience the same problem.
I meet the same problem on RHEL 6.2 system. [root@localhost ~]# rpm -qa | grep guestfs libguestfs-tools-1.7.17-26.el6.x86_64 libguestfs-1.7.17-26.el6.x86_64 libguestfs-winsupport-1.0-7.el6.x86_64 libguestfs-tools-c-1.7.17-26.el6.x86_64 [root@localhost ~]# rpm -qa | grep winsupport libguestfs-winsupport-1.0-7.el6.x86_64 I just shutdown a winxp VM, and get the disk qemu-img resized with 4G extra space. Then virt-resize it using the same command, and I meet the same error output when booting the VM with new disk. I googled around, it seems to be related to wrong BPB in the bootable partition /dev/sda1. This problem can be easily reproduced with a fresh installed winxp VM, and just shutdown it and try to increase disk NTFS partition size using qemu-img and virt-resize. Do you have any idea?
This has been fixed in the latest virt-resize *upstream*. Please try the version in Fedora 16 or above.
(In reply to comment #7) > This has been fixed in the latest virt-resize *upstream*. > Please try the version in Fedora 16 or above. Thanks, Richard. Do you mean that in RHEL6 series, there will not be an update or fix for this problem? Actually, we have some VM running on our RHEL6 cluster meeting the same issue. Anyway, I now workaround it by using guestfish and customized libguestfs application written by me, instead of virt-resize in RHEL6.
Hopefully this will be fixed in RHEL 6.3 (bug 719879).
Closing based on comment 9 and lack of feedback otherwise.