Snapshotting technology is one of virtualization’s key features. No matter if you’re already a virtualization pro or if you’re just now learning about it, you should get Hyper-V snapshots on your side. Today, I’m going to provide you with the 12 things you should know about Hyper-V snapshots.
Hyper-V snapshots aren’t snapshots anymore
As a matter of fact, it’s incorrect to refer to Hyper-V snapshots as “snapshots” anymore. Even though the term is still correct for older systems like Windows Server 2008, Windows 2008 R2 and Windows Server 2012, the technology has been improved in Windows Server 2012 R2 and was renamed to ‘Hyper-V checkpoints’. That was done in order to prevent confusion around Hyper-V snapshots and VSS (NTFS) snapshots, and to keep things consistent. For example, Microsoft System Center Virtual Machine Manager (SCVMM) was previously referring to checkpoints rather than snapshots.
Renaming still might be a bit confusing but it’s official, so it’s easier to go with it. Let’s agree to call the technology the formal way from now on — Hyper-V checkpoints, assuming that you’re on Windows Server 2012 R2 or later.
What is a Hyper-V checkpoint?
Physically, a Hyper-V checkpoint is a differencing virtual hard disk, that has a special name and avhd(x) extension and a configuration xml file with GUID name. In addition, there may be two additional files with virtual machine (VM) memory (.bin) and state of VM devices (.vsv) if the VM was turned on within checkpoint creation. Once the checkpoint is taken, the differencing (.avhd(x)) disk becomes a place where temporary changes to the VM’s original disk are stored, while an original disk remains read-only.
Logically, it’s better to think about Hyper-V checkpoint as a consistent state of a VM in a specific point in time. This means you could preserve this state for a while and revert back to it if something happened with the current state of a VM. Sounds like a backup, right? But, it is not!
Checkpoints are not backups
It’s pretty unfair to think about checkpoints as backups. It’s not a remedy preventing you from data loss or an alternative for backups. Due to its nature, checkpoints are being stored on a production datastore along with VM hard disks. This means, the datastore still happens to be a single point of failure in your system. Any problem occurring with the datastore leaves you without a VM. If you’re not yet convinced, take a look at some facts about backups vs. checkpoints:
- Checkpoints may slow down the entire host as long as you are keeping them
- Checkpoints are lost when the VM’s virtual disk is damaged
- Backups use backup storage elsewhere
- Backups consume less space by using deduplication and data compression
- Backups don’t affect VM performance, after backup completion
- Backups can be restored as a cloned VM, and run side-by-side to the original
Considering the points above, I hope you can see that checkpoints aren’t a viable alternative to a data protection software. Then why would we ever actually need checkpoints?
When to use Hyper-V checkpoints
Let’s put it simple. Use checkpoints in development, testing or acceptance environments but not in production. Period. It’s against all recommendations to use checkpoints on production VMs. Especially on those which provide time-sensitive services like Microsoft SQL Server or Microsoft Exchange Server. It’s never a good option when performance, or the availability of storage space, is critical for the business processes.
Hyper-V checkpoints are great when you need to test something quickly, and the result is visible within minutes. You can preserve a stable VM state and see if your test runs smoothly or if it damages the environment, so then revert the VM back to the stable state.
Examples of short-term tests include a behavior of a new OS patch or a piece of code developed by your backend team for the corporate site.
Checkpoint tree
Before we go into the operations with checkpoint, let’s see how they are organized. This is called a checkpoint tree. In this tree, every subsequent checkpoint stems only from the previous one. So, the actual delta data stored on this checkpoint’s hard disk is a difference between the actual state and a state at last time of checkpoint creation.
This checkpoint tree has a limitation of 50 checkpoints in general. But, there is a way to extend it to 64 by using Virtual Machine Manager in Windows Server 2012 R2. Keep in mind, that reverting a checkpoint to a previous state, or jumping between states, makes the tree deviate.
Figure 1. Hyper-V checkpoint tree
The more the checkpoint tree grows, the more chances that you get disk I/O overhead and the performance of the VM and storage subsystem are degraded. Plus, with this tree growth, you’re getting additional storage consumption. For example, I nearly doubled my results on storage consumption, over the span of a few days, when I tested things on my VM with several checkpoints in the tree.
How to create a Hyper-V checkpoint
Open your Hyper-V Manager, right-click on a VM, or a set of selected VMs, and click checkpoint. Can’t be easier, right? If you’d prefer PowerShell cmdlets for administration, keep reading.
There are several operations you can perform with a created Hyper-V checkpoint: apply, export, rename and delete. Let’s tackle them one by one to make it clear.
Figure 2. Hyper-V Manager. VM with a checkpoint tree
How to rename a Hyper-V checkpoint
By default, a checkpoint name consists of the VM name it belongs to and a time stamp. It might be a good idea to improve the naming system or create yours from scratch. From my personal experience, it’s always nice to have a reason why a checkpoint was taken, along with a time stamp in the checkpoint name. It might sound obvious or like something you don’t have to pay attention to, but it can save your life. What if you forget to delete a checkpoint and it slows down datastore performance, but you simply don’t have time to apply it to find out what is inside?
How to apply a Hyper-V checkpoint
This is the most interesting part. You’ve created a checkpoint, made a test on a VM and figured out that something is not right. This is when you could revert the changes and roll back to the stable VM state. You can do so by right-clicking on a checkpoint tree and selecting ‘apply.’ You then must decide whether you’d like to save this VM state in another checkpoint or not, and start applying the process. Hyper-V will save the VM, restore the desired state from a checkpoint and re-launch it. This process isn’t instant and the VM will be unresponsive for a while, depending on system performance and VM size. Plan accordingly.
Figure 3. Applying a Hyper-V Checkpoint
How to delete a Hyper-V checkpoint
You can delete a checkpoint, but this doesn’t mean that the data it contains will be deleted as well. Deletion is rather a merging operation which unlocks a checkpoint file, transfers its data to the parent disk and then removes the file. What does it mean to delete a checkpoint tree? When you delete a checkpoint tree, you’re removing a selected checkpoint and all subsequent checkpoints.
Note: Don’t ever delete checkpoint disks on the storage, use Hyper-V Manager instead. Otherwise, you’re breaking the tree and it gets useless.
Figure 4. Hyper-V Checkpoint subtree deletion
Here comes a tricky part. Like I said before, Microsoft renamed Hyper-V snapshots to Hyper-V checkpoint since Windows Server 2012 R2. However, if you’re using PowerShell for administration operations, you’ll notice that the re-naming might be a bit confusing. I’ve listed all checkpoint related actions and complemented each with the corresponding PowerShell cmdlet, so you can perform the following operations:
- Create checkpoint with Checkpoint-VM
- Display a list of VM checkpoints with Get-VMSnapshot
- Export a VM checkpoint with Export-VMSnapshot
- Change the checkpoint name with Rename-VMSnapshot
- Apply a checkpoint (revert back in time) with Restore-VMSnapshot
- Delete a checkpoint (merge all data) with Remove-VMSnapshot
Figure 5. PowerShell cmdlets related to Hyper-V checkpoint management
Miscellaneous
Here is a little more information that has not found a place above but still helpful:
- Please don’t expand the virtual disk while it’s in use with checkpoints. The whole checkpoint tree will break.
- The snapshot removal operation in Windows server 2008 (R2) cannot be fully completed until the VM is shut down, turned off or put into a saved state. As a result, the .avhd files that store the snapshot data remain in the storage location until the VM reaches any of those states.
What will Windows Server 2016 bring?
Even though it may be too early to talk about a system which hasn’t been released yet, there is some information about new features and enhancements, including Hyper-V checkpoints available for it. This information based on actual Windows 10 release and Windows Server 2016 Technical Preview versions.
It’s been established that there will be two different checkpoint types: Standard and Production. While standard checkpoints are the checkpoints I’ve been describing in this article, Production Checkpoints are going to be advanced checkpoints for production environment use, as the name implies. They’ll be utilizing VSS on Windows (file system freeze on Linux) to provide data consistency. Thus, it will make the VM state reversion a flawless process and guest OS applications with distributed architecture will be able to handle it correctly. Learn more about newly introduced Production Checkpoints in this blog post.
Figure 6. Hyper-V Checkpoints in Windows Server 2016 Technical Preview 4
More details about Production Checkpoints from Microsoft: https://msdn.microsoft.com/virtualization/hyperv_on_windows/user_guide/checkpoints
What’s your experience with Hyper-V checkpoints? If you have anything to share, please do so below, I look forward to hearing from you.
