One of the first features aside from “vMotion” type technologies from various hypervisors that attract many to virtualization is the ability to take a “snapshot” of the virtual machine. This is a technology that is simply not available when running physical servers. However, the term “snapshot” is really a term that is associated with VMware technology. In the Hyper-V world, since Windows Server 2012 R2, the term that describes the “snapshot” functionality with a Hyper-V virtual machine is a checkpoint.
Hyper-V checkpoints allow administrators to do some really interesting things with virtual machines and provide a measure of flexibility when installing software, performing updates, making system changes, and even when troubleshooting.
Another interesting use case with Hyper-V checkpoints that have been introduced recently in Windows Server 2016 is production checkpoints.
- What exactly are Hyper-V checkpoints?
- What are the various use cases?
- How can checkpoints be utilized in production?
We will take a look at Using Checkpoints with Hyper-V Virtual Machines and the various use cases and configuration to be considered.
What is a Hyper-V Checkpoint and Use Cases?
What exactly is a Hyper-V Checkpoint and what does it allow you to do?
A Hyper-V checkpoint affords Hyper-V administrators the ability to both create and roll back to a known state of a virtual machine quickly and easily. Depending on the type of checkpoint as will be discussed a bit later, this known state can even include the memory information at the time the checkpoint was created. A checkpoint allows Hyper-V administrators to take what amounts to a “photograph” of the virtual machine and all its details that provide that perfect picture of exactly what the virtual machine looked like when it was captured.
When you think about the various use cases that are provided by checkpoints, there are many great examples that come to mind. The following represent great use cases for Hyper-V virtual machine checkpoints:
- Applying operating system updates – Windows Updates and even Linux updates can give administrators call for a pause. If operating system updates go badly, it can leave a virtual machine in a non-bootable state
- Installing new software – Before installing software, especially if it isn’t known what interactions the software may have with other software coexisting on the system, it is a great idea to create a checkpoint just in case problems arise
- Changing the system configuration – Changing Windows Roles or Features, changing IIS configuration, or even network configuration, route tables, installed drivers, etc warrants having a good state to roll back
- Apply registry changes – Modifying the registry can be powerful but also dangerous. If the wrong key is modified, deleted, or added, it can lead to major system issues
- Before troubleshooting an issue – If steps are taken during a troubleshooting session to resolve an issue that ultimately may not resolve the issue, it is good to have a point to go back to before changes were made
- Dev/STG/UAT environments – Checkpoints are a great tool to use in DEV/STG/UAT environments. Before code is rolled in or changed or testing is implemented, checkpoints provide very quick rollbacks to known good states for virtual machines. This allows developers to roll in code, revert, roll in code again, and keep running this process until the code is at a good point for testing
The above use cases provide really good examples of when checkpoints may be utilized by a Hyper-V administrator. By having a checkpoint in place in the above scenarios, administrators can have extremely quick roll back mechanisms in place that can potentially save hours or days’ worth of time.
New Use Case for Hyper-V Checkpoints
With the release of Windows Server 2016, Microsoft has introduced a new use case for Hyper-V checkpoints – production checkpoints.
What is the difference with a checkpoint that is a “production checkpoint”?
Before answering that question, snapshots or checkpoints typically have never been supported as “production” technologies. VMware and Microsoft have regarded these mechanisms as an only very short-term and temporary and not supported with virtual machines that were running production workloads. Microsoft, however, has changed this with Windows Server 2016 and production checkpoints.
Checkpoints prior to Windows Server 2016 contained the virtual machine configuration, state (memory information), and the data on the virtual disk. Starting with Windows Server 2016, these types of checkpoints have been rebranded as standard checkpoints.
Standard checkpoints provide an exact state of a virtual machine, including memory information. When you revert to a standard checkpoint, you will have the exact virtual machine at that particular point in time when it was taken. Even though the standard checkpoint is noted in Hyper-V as being application consistent due to having an exact copy of the memory and disk contents, the Windows guest operating system has no knowledge of the checkpoint that is being taken. Windows do not interact with Volume Shadow Copy service to create the snapshot, so it has no VSS reference point for the standard checkpoint.
With virtual machines running production workloads with applications such as Microsoft SQL Server, this is not good. You always want VSS to be involved in creating a point in time “state” of a Windows Server virtual machine running applications such as Microsoft SQL Server.
Production checkpoints are carried out in a very similar way as the application-aware backups performed by most modern data protection solutions that backup virtual machines. Backup vendors interact with VSS to properly flush data from memory to disk and write pending I/O operations during a backup iteration. This ensures that the backup captures all of the data in a consistent fashion. Production checkpoints perform the same operation by flushing memory and pending I/O operations when creating the checkpoint. This results in applications such as Microsoft SQL Server remaining in a consistent state in the production checkpoint. The production checkpoint is basically an application-aware “image” of the virtual machine. One thing to note with a production checkpoint, when restored, the virtual machine will be powered off. The reason for this is when a production checkpoint is created, the memory contents are flushed to disk, so the virtual machine has no memory “state” contained in the checkpoint. This results in the virtual machine being in a powered off state. This is similar behavior experienced as when a VSS, application-aware image-level backup is restored.
With the characteristics of each type of checkpoint, which use case is each type of checkpoint suited for?
Standard Checkpoint:
- DEV/STG/TEST environments for quick rollbacks
- Quick rollbacks from configuration or other software changes
- If you need to capture the exact state of the virtual machine, including memory
- Not supported in production environments
Production Checkpoint
- If you need to provide backup containing the full application state of the virtual machine
- If you need to take a checkpoint of a virtual machine in production
- If your virtual machine runs applications such as Microsoft SQL Server or any other transactionally aware database
Configuring Hyper-V Virtual Machine Checkpoint Type
As you can see, there are certainly advantages contained in the production checkpoint as opposed to the standard checkpoint. However, each individual use case should be considered when creating checkpoints.
How do you change the checkpoint configuration for a Hyper-V virtual machine?
Navigate to the Hyper-V virtual machine in Hyper-V Manager, right-click the virtual machine and select Settings. Under Checkpoints >> Checkpoint Type select the default checkpoint option. The options are:
- Production checkpoints (selected by default)
- Standard Checkpoints
Production Checkpoints Are Still Not Backups
One thing to keep in mind is that even though production checkpoints are now supported by Microsoft for production workloads and use “backup-like” procedures for application-aware backups that flush memory and pending I/O operations, the data is still contained on the production Hyper-V infrastructure. This means that if you lose storage that contains the Hyper-V virtual machine hard disk files, the checkpoints will be lost as well. True backups of Hyper-V virtual machines should be stored in a way that has no reliance on Hyper-V infrastructure to restore your Hyper-V virtual machine in a disaster recovery scenario.
Concluding Thoughts
Microsoft Windows Server Hyper-V Virtual Machine Checkpoints provide a great way for administrators to capture the exact state of a virtual machine. Windows Server 2016 has introduced a very interesting option for Hyper-V administrators – the production checkpoint. By using production checkpoints, the exact application state can be captured in a true “backup like” process that flushes memory and pending I/O operations to disk. This allows administrators to have a supported checkpoint in production environments. Both the standard and production checkpoints have well-suited use cases ranging from DEV/STG/UAT, development, quick rollbacks, all the way to production environments running production checkpoints.
Follow our Twitter and Facebook feeds for new releases, updates, insightful posts and more.
