There is a lot of differing information concerning the disk space required to delete snapshots and have them merge back into the original VHD in a Hyper-v Virtual Machine.

Usually these conversations are forum posts where Sys Admins have performed a snapshot on purpose or by accident early on in the Server’s life and are now facing the prospect of merging back a massive differencing disk (AHVD) that has consumed what was left of the physical disk. The advice from others is usually to export the Virtual Machine to a larger disk, perform the merge and export and import it back again. This may or may not however be required (depending on your case) and wasn’t in our case, so please read on for a real world scenario.

Hyper-v Virtual Disk Types

Now I think that the varying reports on Hyper-v snapshot merging has come about because there are different types of Virtual Disks VHDs available to you in Hyper-V.

If you run in a production environment the consensis seems to be that running a fixed Size VHD is the best option. When you first create this type of disk it expands out and claims the physical disk space. This process can take a while, howevever with a new physical disk in the system this is great because it will likely claim a chunk of continuous space on the disk. You can expand the disk size in the future if you have more physical space but you can’t shrink it.

A dynamically expanding disk is another type of beast. It is fantastic for a lab because it only consumes from the physical disk what it uses in space. Over time though this type of disk could get so large that it fills your physical storage so beware. There are also overheads in constantly increasing the size of the VHD. I don’t recommend using them except in your lab, but they are important to be aware of in the case of snapshot merging.

Our Scenario

We provide IT Support on the Sunshine Coast and have been working a lot with Microsoft Virtualisation technologies. For this client we provided a 2008 R2 box running Hyper-v and a virtualised SBS 2011 running in it. It was a new install and a snapshot had been taken during the install process. Now Microsoft recommends not taking snapshots ever this to a production machine or any DC (there can be issues in rolling back to a snapshot) so don’t do it. There seemed to be no harm done in this case. Also, the snapshot button is so close to the VM Start that you might even accidentally hit it one day. A word to Microsoft – a great idea would be a switch to globally disable the ability to Snapshot.

The server had been happily running for a week and then we found the disk space was decreasing too fast on the host. Further investigations showed the snapshot was still on the system and the snapshot AVHDs had grown in size for the primary System VHD and the Data VHD. The Primary System VHD was 188Gb and the snapshot AVHD had grown to around 47Gb. The Primary Data VHD was 270Gb and the AVHD 12.5Gb. The original VHDs were Fixed Size disks which really helps in the merging scenario.

The Backup

We took a Hyper-v export of the Virtual Machine to an external drive as a precaution before performing the merge because of all the horror stories on the internet regarding merging. This is one of Hyper-v’s best features and allows you to move an entire virtual machine to another Hyper-v host if required. Simply shut down the Virtual Machine and then choose export from the sidebar menu (the option is not available when it is running).

The Merge into Fixed Disk VHDs

The actual merge was suprising. Being a fixed disk the differencing disk is played back into the existing space used by the VHDs. Here is a screenshot of part way through the process. The key was that there was absolutely no change in the physical space used on the hard drive. No these drives were RAID 10 SAS 10K so they perform well. The entire merge took 15 minutes from start to finish. That is merging around 60Gb of differencing disk.

As the process got towards the end the physical disk actually gained some free space as one of the AVHDs was probably deleted in the merge.

The AVHDs in this scenario were manageable. We haven’t tested it but there may be a problem if the AVHD gets bigger than the original Fixed size VHD. How that scenario would be realised I am not sure because of the physical limit on the original VHD – please comment if you have experienced in this.

But what about Dynamically Expanding VHDs

Well we haven’t tested this case in production, but Mooky32 on the Windows Server Forums has posted some lab tests in which he found that with a dynamically expanding disk you will require free physical space of up to the current size of the AVHDs you are merging. In our case that would mean we would need 60Gb of free space to perform the merge. This makes sense because as the AVHD is played into the dynamically expanding VHD it would need to expand out. Where this seems to be a problem for other admins is where a snapshot has gone un-noticed for some time and has taken up a majority of the physical drive leaving no space to expand the original VHD. In this case you would be forced to perform an export to a drive with enough free space, merge and then export and import back.

Conclusion

Our production result confirmed what Mooky32 found in his test lab. With the merge of a AVHD that was smaller than the original Fixed Size VHD, we found there was NO requirement for additional free space on the drive. Also the speed at which the merge occured was suprising.

Disclaimer: We are providing this information as background reading. Please consult official Microsoft documentation before performing any of the tasks outlined in our article. We do not accept responsibility for any loss, expense or liability that you may incur from using or relying on the information contained here.