Managing Hyper-V Snapshots (Part 3)

If you would like to read the other parts in this article series please go to:

Introduction

In the previous article in this series, I showed you how to rename Hyper-V snapshots so that it would be easier to keep track of the reason why the various snapshots were created. Of course keeping track of snapshots is only a portion of the snapshot management process. Occasionally you may need to revert a virtual machine to a previous state by using a snapshot. Likewise, you may sometimes find that you need to consolidate your snapshots. In this article, I will conclude the discussion of Hyper-V snapshots by showing you how it’s done.

Snapshot Consolidation

In the previous article you saw that it is sometimes possible to accumulate a large number of virtual machine snapshots. You can end up with so many snapshots in fact that you may need to rename the snapshots just so that you can keep track of why each snapshot was created.

Even though Hyper-V allows you to create as many snapshots as you want, keeping a large number of snapshots on hand is usually a bad idea unless you have a compelling reason for having a large collection of snapshots. As discussed in the first article in this series, snapshots can diminish read performance for Hyper-V virtual machines. The more snapshots you accumulate for a specific virtual machine, the greater the potential for the virtual machine’s performance to be degraded. As such, it is usually advisable to keep only the snapshots that you need.

When it comes to removing unwanted snapshots, you cannot pick and choose random snapshots to remove (depending on the version of Hyper-V that you are using). The reason for this is that the snapshots are all based on one another. When you create a snapshot, what you are really doing is creating a differencing disk. All future write operations for the virtual machine are redirected to the differencing disk so that the virtual machine’s original virtual hard disk file can remain in a pristine and unaltered state.

When you create a second snapshot for a virtual machine you are actually creating yet another differencing disk. At this point, all of the virtual machine’s write operations are redirected to the new differencing disk. The original virtual hard disk remains unchanged since the time that the first snapshot was created. Likewise, the differencing disk that’s associated with the first snapshot becomes read only as soon as the second snapshot is created.

The important thing to understand about the way that the snapshot creation process works is that differencing disks do not contain a full copy of the virtual machine’s virtual hard disks. A differencing disk (and therefore the snapshot that is associated with the differencing disk) contains only deltas that have occurred since the time that the snapshot was created.

So what does all of this have to do with snapshot consolidation? As you will recall, at the beginning of this section I mentioned that depending on the version of Hyper-V you are running, you may not be able to delete random snapshots because all of the snapshots are tied to one another. Let me show you exactly why that is the case.

If you look at Figure A, you will see a large collection of snapshots for a virtual machine named Core. The first snapshot (the one at the top of the list) was created on March 1st 2013 at 8:43 PM. Any data that was written to the virtual machine before this date and time resides in the virtual machine’s original virtual hard disk.

Figure A: You can sometimes end up with a huge collection of virtual machine snapshots.

The second snapshot on the list was created on March 1st 2013 at 9:09 PM. This means that at 9:09 PM the contents of the first differencing disk became read only, and all of the write operations were redirected to the second virtual hard disk. Eleven seconds later I created a third snapshot. This created yet another differencing disk, and in doing so caused the second differencing disk to be designated as read only.

Obviously the snapshots that are shown in the figure above were created on a lab server, solely for demonstration purposes. Even so, let’s pretend that there had been a legitimate business need behind the creation of each of these snapshots. Let’s also pretend that some time has passed now, and that I am evaluating the various snapshots to determine which ones are needed and which ones are not. Finally, let’s imagine that I decided that I needed to keep the first snapshot and the third snapshot, but decided that I didn’t need the second snapshot.

Deleting the second snapshot isn’t an option because it contains every write operation that occurred on March 1st between 9:09:38 and 9:09:49 PM. This snapshot contains the only copy of those write operations, and the system is actively using the corresponding virtual hard disk (for read operations).

Even though each snapshot’s differencing disk is being actively used by the system, Hyper-V 3.0 (Windows Server 2012) allows you to delete random snapshots within the snapshot tree. However, when you delete a snapshot in Hyper-V 3.0, you are not actually deleting the data that’s contained within the snapshot. Remember, the virtual machine is actively using that data. Instead, the data that is stored within the differencing disk is merged into the next snapshot. That way, the unwanted snapshot’s underlying differencing disk can be removed (which tends to improve performance), but there is no data loss as a result of the deletion.

To delete a snapshot, simply right click on the unwanted snapshot and choose the Delete command from the resulting shortcut menu, as shown in Figure B.

Figure B: To delete an unwanted snapshot, right click on the snapshot and choose the Delete command from the shortcut menu.

As you look at the previous figure, you might notice that the shortcut menu also contains a Delete Snapshot Subtree option. Choosing this option causes Windows to delete the selected snapshot and every snapshot that was created later on. In doing so, all of the data stored in the underlying differencing disks are merged into the current differencing disk.

Applying a Snapshot

The main reason for creating snapshots is that snapshots give you the ability to roll a virtual machine back to an earlier point in time. If you decide that you need to roll back a virtual machine, you can do so by right clicking on the snapshot that represents your desired roll back point, and then selecting the Apply command from the shortcut menu. You can see the Apply command in Figure B.

When you choose the Apply command, you will see a warning message telling you that the virtual machine’s current state will be lost (because you are reverting to a previous state). As you can see in Figure C, Hyper-V gives you the option of taking a snapshot before you apply the snapshot. Taking a snapshot before applying a snapshot gives you a way to get back to your current state if you happen to accidentally apply the wrong snapshot.

Figure C: You have the option of taking a snapshot before applying a snapshot.

To see how this works, take a look at Figure D. As you can see, the virtual machine’s current state is based on a snapshot that was created on March 1st 2013 at 9:10:03 PM. This is the snapshot that I applied. The subsequent snapshots exist because I told Hyper-V to take a snapshot before applying the snapshot. Had I not done so, the 9:10:14 and 10:10:34 snapshots would have been deleted when the 9:10:03 snapshot was applied.

Figure D: The virtual machine’s current state is now based on an earlier snapshot.