One of the problems when you ship a beta product with a released product is that people will use it. Damn those users!

Yeah, well, I’m one of those users and it’s all very well including a comment in the Hyper-V beta release notes warning us that it will not be possible upgrade VMs from the Hyper-V beta to subsequent releases (I think there was such a comment, but I can only find the RC0 release notes now) but someone is just going to do it. I figured that as long as I have the virtual hard disk (.VHD) then recreating a child partition (virtual machine) shouldn’t be too big an issue. Right?

The exact words in Microsoft’s instructions for installing the Windows Server 2008 Hyper-V RC are:

“Migration of virtual machine configurations from Hyper-V Beta is not supported. All virtual machine configurations must be recreated using Hyper-V RC. However, customers will be able to migrate VHD files for released operating systems (Pre-release version of Windows Server 2008 will need to be recreated with the RTM version). There are several important factors to consider and steps to be followed for migrating VHDs to Hyper-V RC. […] Please refer to http://support.microsoft.com/kb/949222 for instructions on how to move VHDs created on Hyper-V Beta to RC.”

What Microsoft knowledge base article 949222 fails to point out is that the process of deleting snapshots does not always complete successfully. As John Howard points out in his recent post about the availability of the Hyper-V release candidate (RC) release:

“If you have any virtual machines running on Hyper-V Beta which have snapshots, these are not compatible with Hyper-V RC0. Deleting the snapshots will cause the changes to be merged back to the parent VHD, but this does take some time to complete (and due to a bug in Hyper-V beta, the merge does not always kick in).”

If you suffer from the bug that John mentions, there is a workaround (unsupported), which is under NDA (so I can’t write the method here), but Ben Armstrong gives a pretty big clue when he describes virtual machine snapshotting under Hyper-V and says:

“You can also delete a snapshot. If you delete a snapshot that has no descendants (snapshot with differencing disks that reference the snapshot being deleted) then the files associated with the snapshot will just be deleted. If you delete a snapshot with only one descendant the configuration and saved state files for the snapshot will be deleted and the snapshot differencing disks will be merged with those of it’s descendant. If you delete a snapshot with more than one descendant the snapshot configuration and saved state files will be deleted – but the differencing disks will not be merged until the number of descendant snapshots is reduced to one.”

I added the emphasis in that quote and it may be useful to note that the Edit Virtual Hard Disk Wizard can be used to merge a differencing disk (which is what a snapshot is) into it’s parent (from the Windows Server 2008 Technical Library).

Thankfully, I didn’t have to go down that route (at least not on my notebook – I’ve not been brave enough to upgrade my server at home yet as I’ll also need to upgrade the parent partition from escrow build 6001.17128.amd64fre.longhorn.080101-1935 to RTM build 6001.18000.amd64fre.longhorn_rtm.080118-1840 – you can check what version a server is running by examining the BuildLabEx string at HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\ in the registry). When I tried to take a backup of all the VM files (including snapshots), I found that some of them were locked – even after a reboot. That was because Hyper-V was (very slowly) merging the contents of the .AVHD files into the .VHDs. I wasn’t convinced until I saw .AVHD files disappearing before my eyes and disk space miraculously appearing on my hard drive, although I have a feeling that the process may have stalled a couple of times and a reboot kicked things off again.

There are two clues that the merge is not yet complete:

1. The presence of some .AVHD files in the snapshots folder for the virtual machine.
2. The <disk_merge_pending type="bool">True</disk_merge_pending> line in the corresponding XML file.

Once the merge is complete, the .AVHD files should be deleted and <disk_merge_pending type="bool">True</disk_merge_pending> should read <disk_merge_pending type="bool">False</disk_merge_pending> .

After my snapshots were merged and I had removed the beta integration components from my VMs, the upgrade process was quite straightforward – document everything, apply the Hyper-V RC0 upgrade package (no need to remove the beta first), install the RC (including restarting the computer), remove and recreate any virtual machines (even though they may still be visible in Hyper-V Manager, attempting to start one of virtual machines will result in an access denied error – it’s a simple enough process to delete the virtual machine and recreate it using the original virtual hard disk), set up the virtual networking and install the latest integration components (depending on the operating system in use for each child partition).

Thankfully, I shouldn’t have to endure this pain with subsequent releases (like RC0 to RTM) – Microsoft’s Hyper-V FAQ states that:

“Microsoft is encouraging all customers and partners to test and evaluate the RC of Hyper-V. With RC, Hyper-V is now feature complete and provides a seamless upgrade path to RTM of Hyper-V.”

Phew!