I recently dealt with a virtual server, running on a Microsoft Hyper-V Server host (the free version), which needed a lot of TEMP disk space during backup. The VHD file that the guest was running in needed to be resized to make more space. The file was 94 GB. I tried to make it a big bigger and resize it to 104 GB.
The instructions for this proces are simple:
- Shut down the guest
- Edit the guest properties and
- enlarge the disk (enlarge the VHD file)
- Bring the guest back online
Sounds simple, right? Here’s what went wrong:
The disk resize operation took a few seconds and the Hyper-V Server reported that something went wrong. After the failed disk resize the VHD file had become corrupt and the guest could not be started again!
Strange fact was that I was able to mount the VHD with WinImage and I was even able to extract file from the VHD. Basically a VHD file is a big file that holds an image of a hard disk (like an ISO file. When you burn an ISO file to CD or DVD the raw content of the ISO file is written to the CD, so your computer can recognize the files). If WinImage can read the file, why couldn’t I get Hyper-V Server to read it? When trying to start the guest Hyper-V Server reported an error within a few seconds and I couldn’t imagine anything severe being wrong with the file (just the guest server had become unstartable). What was wrong?!?!
I spent a night trying to figure what had gone wrong and trying to solve this mystery. During this night I made lots of backups of the VHD file. I tried converting it from VHD to VHD (maybe that would repair the file or unfold the mystery of the VHD that had suddenly become corrupt). Be advised: copying a 100 GB file from SCSI to USB takes forever and you need to use this time to figure out different scenario’s.
Lots and lots of articles, tools, questions asked in forums and lots and lots of answers, more tools and lots of suggestions, testdisk, partition tools, but I was sure there was nothing wrong with my file, but Hyper-V was wrong!
I converted the VHD to a VDMK file (VMWare’s hard disk format), trying to make it accessible by VMWare ESXi (the free version). The problem with VMWare ESXi is that it’s impossible (believe me, I tried!) to locally transfer a VDMK file from a USB drive onto the ESXi server. I hacked into the ESXi console (type in unsupported at TTY1, hit Enter and log in as root and then, try connect the USB drive, try to find the right /dev/device to mount and try a local file transfer; nothing worked!). Uploading it from a laptop or other PC (or SCP/SSH) simply takes too long just to figure out if it works. I tried connecting my laptop to the host (which I reinstalled with ESXi, after backing up the backup file of the VHD) and I ran into all sorts of trouble with Gigabit Speed-and-Duplex-Autodetect. In the end I had an ESXi host with a gigabit NIC, a laptop with a gigabit NIC, a crossover cable, all settings to Manual, 1 Gbps Full Duplex and yet the connection between the two was only 100 Mbps. Uploading at this speed would take forever and I was forced to come up with another plan…
By this time I got rid of the ESXi and went to Hyper-V based on the “real” Windows 2008 Server, which allowed more direct interaction between the host and the guest. Having a Vista Management PC between the two simply “doesn’t make things easier”. Believe me, guys: The Full Featured Windows 2008 Server Standard has built-in Hyper-V functionality (you need to install the Role, though) and it is well worth the money!
As time went by the birds outside were waknig up and I ran into an online article that suggested to do the following:
- Create a new guest on the Hyper-V host
- Point to the VHD file that you’re trying to repair
- During this process you have an addition option that lets you Edit the VHD file
- and the $1M issue: The Edit button allows you to change the VHD type from Fixed to Dynamic!
Yes, people! When you create a VHD file, your instinct tells you that a Fixed VHD file gives you more performance and stability. The general opinion is that Dynamic VHD files should be avoided, as the file needs to grow when the guest that ‘lives’ in it grows and that takes performance of your host and guest.
After converting the VHD from Fixed to Dynamic the guest was suddenly not corrupt anymore (?!?!) and the guest was startable and worked like a charm! Don’t ask me why you need to Create a New VM for this, but it takes a Hyper-V (free or paid version) seconds to destroy a Fixed VHD file and it took me hours to find out that converting it from Fixed to Dynamic would make it mountable by Hyper-V!
I would call this a bug or an unwanted feature. Anyway: The server was up, the sun was, too and I went to bed.
I don’t wish anybody a corrupt VHD file, but in case you run into one: I hope my story is a life saver! Don’t be shy and leave a comment if it did 🙂 Happy hacking!