It's nothing but a "snapshot". 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.

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?

Let us take a look at Using Checkpoints with Hyper-V Virtual Machines and the various use cases and configuration to be considered in this Howto.

3 Steps total

Step 1: 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.

Step 2: 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

Step 3: Configuring Hyper-V Virtual Machine Checkpoint Type

As said above, 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?

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.

References

11 Comments

I would think the term snapshots have been use by the IT industry for a very long time including M$.

Somehow they wanted to sound special so they re-invented the wheel and gave it a new name...causing so much confusion.

There are backup software that uses "checkpoints" as means of quiescence the VM....or is that term also now "not preferred by M$ ?"....but the backup software have means of removing that checkpoint.

So it can be generally that checkpoints or "VMware snapshot" of VMs are a method to preserve the VMs "state" before Windows update or any updates as to a means of rollback. But it should be mentioned that a full backup of the power-off VM should be considered as the most conservative and preferred method to preserve the VM especially for major updates and/or software installation.

We run Hyper-V in my environment and I have used Server 2012 R2 checkpoints for restore my CRM VM multiple times without any issues. I have never seen any issues restoring this VM and it has always worked.

The VM is a Server 2008 running Microsoft Dynamics CRM (if that's not 'transactionally aware' I'm not sure what is) Just mentioning it because in your column you are stating that you must have Server 2016 to do this type of restore but I do it regularly with 2012.

VMware linked clones should be considered "production checkpoints" and I was using linked clones for production machines in 2011. The way they work is you have a master image and each clone is actually a snapshot of the master disk. The upside is rapid deployment, the downside is systems used for long periods end up with a snapshot bigger than the parent disk and need to be full cloned to recover datastore space.

This article is okay, but really should discuss the importance of deleting old checkpoints when finished. When the first checkpoint on a system is created, Hyper-V locks all of the vhd/vhdx files for the VM and creates corresponding avhd/avhdx files. The avhd files are change logs of every change that should be applied to the vhd. However, while the vhd file is locked to a maximum size (either pre-allocated or dynamic) the avhd files are unrestricted. They simply log every change since the snapshot. Any additional checkpoints freeze the previous avhd and start another file. Left unchecked, avhd files can consume all the free space on their host drive. Even if free disk space isn't a concern, performance starts to take a hit because Hyper-V needs to analyze a changelog instead of vhd.

JerrySeltzer is spot on - i've had unmonitored hosts run out of space due to the avhd files eventually taking up all the free space on the drive.

Something else to keep in mind is that you need a lot of space to merge checkpoints when deleting them. Hyper-V does not make sure you have enough before it starts merging. You can run out of space before the merge is complete.