Recovering from HyperV failure
It finally happened. A virtual machine refused to startup. It has unknown boot errors. So we just delete the VM and recreate it using the base VHD that it had. All the snampesots (avhd files) were intact. So a google search shows:
Microsoft MVP Brian’s IT Proctology blog with the following data:
You manually merge your snapshots into your base VHD before you boot your VM. (I am assuming that you know how to connect to an existing VHD using the new VM wizard).
Merging of snapshots can be performed manually. This is achieved by:
On your Hyper-V host.Power off the Virtual Machine.
Make a copy of the VHD and its corresponding AVHD files.
Rename the AVHD extension to VHD.
Write down the order of the disks from youngest to oldest (the oldest should be the root VHD). You can do this by looking at the last modified time stamp on the origional AVHD files, find the one that last changed. And find the last one that changed before it.
In the Hyper-V manager, open the Edit Disk wizardBrowse to the youngest VHD in the chain, then choose ‘reconnect’ to point to the next youngest (the one that came before).
Open the Edit Disk wizard a second time and merge.
Then repeat the process until you have only a single VHD.
In a disaster case, you need to recover a copy of the root VHD prior to attaching it to a new VM and booting it (the act of booting it, modifies it)
Usually the most difficult part of this process is finding the last AVHD (differencing disk) in the chain.
The easiest way to do this is to find the configuration file for the VM.
Virtual Server 2005 R2 SP1 includes a tool called VHDmount that allows you to mount a virtual hard disk (which in fact is a .VHD file) directly on your host operating system. VHDMount is provided as a command line tool. You can perform various tasks by either running it directly from the Command Line, or by using simple batch files that do what you need to do. Some of the capabilities of VHDMount are:
/p – Plugs in the specified VHD as a virtual disk device without mounting the volume.
/m – Plugs in the specified VHD as a virtual disk device and mounts the volume.
/f – Performs the specified operation without creating an Undo Disk. This parameter is applicable for /p and /m. All changes to the mounted disk are directly written to the specified VHD.
/u – Unplugs the virtual disk device for the specified VHDFileName.
/c – Updates the original VHD with all changes that were stored in the Undo Disk anddeletes the Undo Disk after unplugging the disk. This parameter is only applicable if the VHD was mounted without using /f.
/d – Discards all changes to the mounted disk and deletes the Undo Disk after unplugging the disk. This parameter is only applicable if the VHD was mounted without using /f.
/q – Displays the disk name of the mounted virtual disk device for the specified VHDFileName.
VHDFileName – VHD name including full path.
DriveLetter – Optional parameter for /m option. If drive letter is specified the volumes are mounted starting at the specified drive letter. If drive letter is not specifiedit is automatically assigned.
All – Applies the operation on all mounted virtual disk devices. This parameter is applicable for /u and /q.
By default, VHDMount creates an Undo Disk in current user’s temporary folder. All changes to the mounted disk are written to this Undo Disk. Use /c to commit or /d to discard these changes at the time of unplugging the disk device. Use /f option to mount a VHD without an Undo Disk.
Examples:
VHDMOUNT /p [/f] VHDFileName
VHDMOUNT /m [/f] VHDFileName [DriveLetter]
VHDMOUNT /u [/c | /d] VHDFileName | All
VHDMOUNT /q VHDFileName | AllA huge thanks to you Brian. However, in my case, there was some read errors in the avhd files. So i decided to use the VHDmount tool instead as outlined in Petri knowledge base:
The idea is that if i can access the files in the vhd (or the renamed avhd file), then i should be able to copy the files (sql backup) needed to update my installation!
I havent done this yet, so at this writing, I am still going to find out soon 🙂
Update: I finally figured out where what we were doing wrong. I started from the oldest instead of starting from the newest snapshot, and going backwards to the NEXT oldest snapshot.
When the wizard asks for ‘parent’ to connect to, just use the next oldest snapshot. It is typically also listed in the wizard 🙂
Filed under: Computing
