Hyper-V Snapshots: Suggestions for Success

Hyper-V Snapshots: Suggestions for Success

  • Comments 2
  • Likes

While working with customers, I have frequently run into situations where they need help with Hyper-V snapshots. Help with understanding what snapshots are, how to use them, best practices with them, or, in worst case scenarios, they may need help in recovering them in order to use a VM.

What I’d like to do in this post, is run down some quick and helpful topics that will keep you on track to being successful each time you use the Hyper-V Snapshot feature.

Do not use Snapshots as a backup strategy


Snapshots can be very useful during the ‘Test and Development’ stage in your environment. And in fact, that’s pretty much what they were designed for.
Snapshots should not be used in a production environment as a replacement for having a well thought out backup strategy.
There are multiple backup solutions and configurations available for Hyper-V at this time and I’ll have some links at the end of this post for more information.

We encourage our customers to use Snapshots in a production environment prior to patching servers. This creates a point in time to fall back to if something doesn’t go according to plan. Once the patch or other system update is applied successfully to the VM, I usually suggest letting the VM run a day or so, and if it’s operating as expected, remove the Snapshot.

Manually interacting with Snapshot files


Snapshot files have long file names made up of the GUID associated with the Virtual Machine they are from and have extensions of .AVHD, .XML, .BIN, and .VSV. I’ve run into a couple of instances where customers have found these strange files, and not knowing what they were, removed them because some were rather large and the server was low on disk space. In these instances, the customers run into problems when rebooting the VMs that had Snapshots configured because the files are now gone

If you need to use Snapshots in your testing environment, and you are not using R2, I suggest the following configuration changes to avoid running space concerns with the system volume:


Change the default location of where Virtual Machines will reside.
Place this location on other media than the system volume to avoid running out of space.
Choose a location that is sufficiently large enough to accommodate the number of snapshots you expect to have in your environment.

Fig.1a shows you were to make these location changes within Hyper-V Manager.
image

Fig.1a

If you are using R2, then as previously mentioned, the Snapshot location will  default to the same location as Virtual Hard Disks.

A key thing to remember with snapshots is that moving, renaming, deleting, or otherwise altering files associated with snapshots may result in the associated VM not working properly next time it’s restarted.
Once a snapshot, or multiple snapshots are created for a VM, all of the associated files must be present when the VM starts in order for the process to be successful.

The “Merge Rule”

Another area where customers can sometimes run into some trouble with snapshots is when they want to start pruning their snapshot tree and they aren’t sure which ones will be merged and which ones will be outright deleted.
This is where “The Rule” comes in:

1) If there are snapshots above the current running state (Now) that are deleted, then a merge will occur when the VM is shut down, turned off or saved.

2) If there are snapshots below the current running state (Now) that are deleted, then a merge will NOT occur when the VM is shut down, turned off or saved.

When a snapshot is deleted, saved state files (.bin and .vsv) get deleted immediately, even if a merge will occur when the VM is shutdown, turned off, or saved.
When you delete a snapshot, the .avhd file(s) that store the snapshot data remain in the storage location until the virtual machine is shut down, turned off, or put into a saved state

NOTE: What happens to the AVHD file(s) depends on the location of the deleted snapshot relative to the running state of the VM as noted in the 2 part table above.

Change Control


In the times where customers have ended up needing to call into support for help with recovering from deleted snapshots, or have needed some other type of assistance with a heavily nested snapshot tree, I have noticed that only rarely have they taken the little extra effort to rename the snapshots to something effective and descriptive.
Choosing the default naming convention is fine for 1 or 2 snapshots, but frequent snapshots result in a multi-branch, multi-level  listing; not having the snapshots named something effective can result in conversations having a lot of “I don’t know”’s in them.

Fig.3 shows an example of what it would look like with the default names being chosen.
image

Fig.3

As you can see by this example, this is not a very clear indication of the differences between the snapshots on the 20th, versus the one I took on the 21st.

How to rename your snapshots


One thing you’ll notice is that when you right click a VM through Hyper-V Manager, and choose snapshot, you don’t get a choice of names. It just stamps the snapshot with the VM name, date and time. How boring!
There’s two ways you can add some helpful text to these titles.

1.    You can right click on the snapshot of your choice and choose the rename option as shown in Fig.4
image

Fig.4


2.    From the VMConnect window, select Action and then Snapshot as shown in Fig.5 and Fig.6, and you will be prompted to choose a name.
image

Fig.5
image

Fig.6


Choosing descriptive snapshot names may take a few seconds extra time up front, but in my experience, this effort can save hours of labor on the other end should there be a need for troubleshooting of a problem.

In closing I wanted to summarize some quick Best Practices when dealing with snapshots.

Best Practices


Do not use them as a backup strategy
DO use them for point in time “safety nets” during patching or VM system updates.
Do not store snapshots on the C:\ drive.
Do not move, delete, rename, edit, the associated snapshot files.
DO make sure you name your snapshots in a helpful & descriptive manner

I hope you found this post helpful!

Sean Dwyer
Support Escalation Engineer
Microsoft Enterprise Platforms Support

Additional Information:
Ben Armstrong’s blog: Virtual Machine Snapshotting under Hyper-V
http://blogs.msdn.com/virtual_pc_guy/archive/2008/03/11/virtual-machine-snapshotting-under-hyper-v.aspx
Ben Armstrong’s blog: Managing Snapshots with Hyper-V
http://blogs.msdn.com/virtual_pc_guy/archive/2008/01/16/managing-snapshots-with-hyper-v.aspx
Hyper-V Snapshot FAQ
http://technet.microsoft.com/en-us/library/dd560637(WS.10).aspx
Video discussion with Ben Armstrong discussing Snapshot common issues.
http://www.microsoft.com/showcase/en/us/details/c47aee4d-b89a-47b5-8c38-3a1d6e1997cf

Backing up VMs:
How to backup Hyper-V vms using Windows Server Backup
http://support.microsoft.com/kb/958662

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • Hi I have a question, a college has removed a snapshot form the server directly to free up HDD space.

    now as you discribed we can not start up this vm anymore.

    Is there a solution to start this vm back up now there has been a snapshot manual deleted?

  • Hi Tom , yes there is a way to start the VM , When you created this sanpshot your VM was starting with the .avhd file and now that .avhd doesn't exist now to bring the VM up you have to point the VM back to the Origional .VHD file .

    I hope this will be helpful .