Hyper-V has a feature I’m sure you may have read about or even seen in action called “snapshots”. Whilst it sounds obvious what these are, its not quite as obvious as it sounds and comes with some pitfalls that many Administrators have been burned by. I thought I’d take a moment to explain exactly what happens when you take a snapshot of a running virtual machine under Hyper-V. When you create a snapshot here is what actually happens:
- The running virtual machine is momentarily paused (users will not notice this happening)
- A differencing disk is created for each virtual hard disk associated with the virtual machine and linked directly to it (on the fly)
- A copy of the Virtual machines configuration file is created
- The virtual machine is resumed
(The above all happens very quickly and you shouldn’t notice it happen - the running machine won’t miss a beat!)
Once the Virtual machine is resumed and running again the information stored in the virtual machines memory is written down to disk. As this happens the snapshot process monitors the memory activity within the running virtual machine for any changes that may occur whilst the copy is in progress, if anything changes in the small amount of time all this takes to complete the write process is intercepted, paused, and the original memory contents are copied before the changes are allowed to proceed to disk (This can cause a running virtual machine to hang for a second as this occurs but the machine will catch up and recover every time).
When all of this is complete you are left with a complete virtual machine configuration file, the virtual machine saved state files and the newly created “snapshot” or “differencing” disk/s (These are saved down to the disk as .AVHDS files – as opposed to VHD files common to normal virtual machines) and are usually located in a sub folder of the Virtual machines original snapshot directory (this was setup when you created the virtual machine initially). This snapshot is now treated as a roll back point for the virtual machine and when applied to the running virtual machine (usually after a fault or bad installation maybe) tells the system to start the virtual machine from the copy. Think of it as a more radical version of system restore but for whole operating systems!
What is important to note here is that once a snapshot is created, any changes made in that Virtual machine from that point on are no longer written to the original VHD file but are now written to the differencing disk (or AVHD file) created by the snapshot process. This process is repeated each time you create a snapshot. So each snapshot results in an additional AVHD file (differencing disk). This means lots of IO. More snapshots equals more IO.
The really bad part of snapshots! – if you delete them, they seems to simply disappear. Great! Not at all – once deleted each snapshot then has to merge the contents of its differencing disk back into the main initial VHD file that makes up the virtual machine. This, depending on when the snapshot was taken and how much data may have changed since that point, can take quite a while. This merge happens when you next reboot the Virtual machine. I have seen VM’s under Hyper-V with a dozen snapshots over say a year in time take 48 hours to merge once deleted.
Conclusion:
- Only delete snapshots when you know you have a window of time to reboot the VM afterwards to allow the merge to complete.
- Only use snapshots before making significant or risky changes to a VM – its not a backup policy, find a better solution like DPM.
If you have used this feature in Hyper-V and don’t understand it – give us a call and I’m sure we can help you out. PTB are one of the only IT support vendors in the UK to attain a Gold Competency from Microsoft for Virtualisation
