Working with Hyper-V Snapshots in the Private Cloud (Part 1)

If you would like to be notified when Deb Shinder releases the next part of this article series please sign up to the Real time article update newsletter.


Many companies are not yet ready to trust their applications and data to a public cloud provider, but want the benefits of cloud technology. They’re opting to move to a private cloud model, which in many ways gives you the best of both worlds. Microsoft offers a comprehensive private cloud solution, and in this article we’ll look one of the cool things you can do with their technology: create and use Hyper-V snapshots in the private cloud.

Understanding snapshots

When working with a Microsoft private cloud, you have the option to create snapshots of the virtual machines that are participating in your private cloud. A snapshot is a copy of the exact state of the virtual machine at a certain point in time. The snapshot contains what was in memory at the time of the snapshot, the number of processors assigned to the virtual machine, all of the disks assigned to the virtual machine, the state of the applications running on the virtual machine, and the state of the services running in the VM at the time of the snapshot, such as virtual network interfaces.

You can take a snapshot of a machine while its running or you can shut down the virtual machine and then take a snapshot when the machine is turned off. If the machine is on, you won’t have any downtime when taking the snapshot. The virtual machine will continue to run when you take the snapshot. Another thing to be aware of is that the operating system running on the VM when you take the snapshot doesn’t matter, so you can be running Windows, Linux, Unix or any other OS that’s supported by Hyper-V in your private cloud. Snapshots are enabled by Hyper-V, not by the guest operating system, so as new operating systems are supported by Hyper-V, those new operating systems will support snapshots as well.

It is important to note that this operating system agnostic approach to snapshots is not the same as the volume shadow copy feature included in Windows that enables you to take snapshots for backups. When taking snapshots in the private cloud, you are only capturing the current state of the machine – the applications running in the virtual machine are not necessarily put in a state where they would be ready for a backup when doing snapshots.

Using snapshots

When using the Hyper-V private cloud, you can take as many as 50 snapshots of a virtual machine. Snapshots are very useful in that they allow you to return the virtual machine to a specific configuration that existed for that virtual machine at a specific point in time. This allows you to roll back to a known working configuration if you’ve made changes that caused problems. Perhaps less obvious, it also allows you to roll back to a known “not working” configuration so that you can investigate potential problems with configurations you’d like to deploy in the future. All of this makes testing much easier and reduces the number of surprises you might encounter when you move from the testing stage to pilot to a full-on deployment.

You can also use snapshots to create multiple test paths. For example, take a look at the figure below. This a collection of test paths Tom used when creating a number of Test Lab Guides for Unified Access Gateway 2010 and DirectAccess. In the figure, you can see that there are numerous snapshots taken for a collection of virtual machines that are participating in a particular scenario, and each test path leads to a completed Test Lab Guide configuration.

Figure 1

What’s great about this is that you can easily return all the virtual machines to a specific snapshot and redo the configuration settings. This allows you to learn the configuration faster and more easily. In addition, you can try out new configuration settings and even install third party software solutions to find out how well they work in a particular configuration before investing money in them and deploying them on your production network.

A closer look at snapshots

Notice that the snapshots have a tree structure, similar to what you would see in the left pane of the Windows Explorer or a Microsoft Management Console. By default, each snapshot is given a name that includes the date and time the snapshot was taken. However, you can right click on the snapshot and rename it so that you will have a better idea of the scenario you were testing at the time you took the snapshot. When working with a multiple virtual machine scenario (such as the Base Configuration used in the Test Lab Guide series), I prefer to shut down each of the virtual machines before taking the snapshot, and I shut down all of the machines in the Base Configuration and snapshot them and then rename them, even if I’m not using all of the machines for that particular scenario. This enables me to have a consistent view of all of the that are machines participating in the Base Configuration – something I wouldn’t be able to see if I didn’t take a snapshot of all the VMs.

When you’re ready to take a snapshot, click on the virtual machine name that you want to snapshot and then either right click on it and click Snapshot or click the Snapshot command in the right pane of the console, as seen in the figure below.

Figure 2

Remember that when you take a snapshot, it saves the exact state of the machine that you’re snapshotting. If a running machine is snapshotted, when you restore that machine, it will be restored in a running state. When you snapshot a machine that was shut down when you took the snapshot, it will restore to a turned off state. Because many networking scenarios are impacted by snapshots that are in a running state, I prefer to take snapshots when the machines are turned off. That way, I can intelligently decide which machines to turn on and in what order to turn them on, so that dependent services become available in the right order.

Storing and organizing snapshots

The virtual machines and snapshots need a place to live – and that requires storage space. If you plan to take a lot of snapshots, make sure that you have a lot of storage capacity. This is especially true when taking snapshots of running machines. Snapshots of running virtual machines are going to take a lot more space than virtual machines that are snapshotted when the virtual machine is turned off. This is another reason that I like to take snapshots of virtual machines when they’re turned off. Of course, there are some scenarios that are relatively simple, in which case I might take snapshots of the virtual machines when they’re turned on.

I always create dedicated folders in which to keep my virtual machines, and in many cases I will create folders for particular scenarios. The figure below shows the folders in my “VMs” folder. You’ll see some of the scenario folders here – such as the NAP_Scenario folder.

Figure 3

In the Base Configuration folder, you’ll see the names of the virtual machines that participate in the core Test Lab Guide Base Configuration, as seen in the figure below. There are additional machines in this folder, that were added by various Test Lab Guides and other scenarios that are based on the Base Configuration for Test Lab Guides.

Figure 4

In the figure below, you can see the contents of the Snapshots folder. The names of the folders and files you see here are their GUIDs (Globally Unique Identifiers). Hyper-V uses these names to keep track of the virtual machines, rather than the names that you assigned to them when you created the virtual machines. The reason for this is that there’s a chance that you might give two or more virtual machines the same name. That would create a name collision in the file system and cause all sorts of confusion, so Hyper-V uses GUIDs to get around that problem. There is an infinitesimally small chance that you’ll get a GUID collision.

Figure 5

File types

When you navigate the folder tree, you’ll see several different file extensions representing the different file types that are used. These include:

  • .vhd. This file represents a virtual hard disk.
  • .avhd. This file represents differencing disks that contain the changes between the original state of the virtual hard disk and the state of the hard disk when you took the snapshot. These contain incremental changes.
  • .vsv. This file contains the contents of the virtual machine’s memory when the snapshot was taken.
  • .bin. This file is a placeholder for the saved state file. The purpose of creating this file is to make sure that there is enough room to save the state of the virtual machine when the virtual machine is shut down. Essentially, what this file does is reserve storage for the virtual machine so that if you want to save the state in an emergency, you’ll be able to do so.
  • .xml. This file contains the configuration information for the virtual machine. The configuration information is the set of configurations you make to the virtual machine through the Properties dialog box for that virtual machine. Contents include things such as the virtual networking configuration, how much memory is assigned to the virtual machine, which hard disks (.vhd’s) are used by the virtual machine, and other virtual machine specific settings.

These files are important for saving the state of the virtual machine when you perform the snapshot. At this point we need to think of the key purpose of taking snapshots. What is it? To restore them! Your private cloud Hyper-V server needs this information to restore the snapshot to the state the virtual machine was in when you took the snapshot. We’ll talk about restoring snapshots in part two of this series on using snapshots in your private cloud.


In Part 1 of this article we discussed what snapshots are and how you take and use them in your Microsoft Private Cloud. Snapshots enable you to save the state of a virtual machine in your private cloud so that you can return the virtual machine to the state it was in at the time you took the snapshot. You can take a snapshot when the virtual machine is running or you can take it when the virtual machine is shut down. Remember that less disk space is required for virtual machines snapshotted in the shut down state. We also talked about how you can use snapshots for testing and how they can be used with Test Lab Guides. Finally, we covered the types of files that are created when creating and using snapshots and what types of information are stored in each of the files. In the next article in this series, we’ll talk about restoring snapshots and what we can do with them in practical usage. See you then! –Deb.

If you would like to be notified when Deb Shinder releases the next part of this article series please sign up to the Real time article update newsletter.

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top