Wondering how to choose between Standard or production checkpoints in Hyper-V? We can help you.

We’ve experienced that Hyper-V can crash anytime. In such a case Standard or Production checkpoints can help us export our data from losing.

As part of our Server Management Services, we assist our customers with frequent Hyper-V queries.

What are Standard or Production checkpoints?

Standard or Production checkpoints help us store our data in case of an unexpected crash or failure.

Production checkpoints are “point in time” images of a virtual machine that we can restore later. This is accomplished by using backup technology within the guest to create the checkpoint.

On the other hand, standard checkpoints capture the state, data, and hardware configuration of a running virtual machine. They can be useful if we need to recreate a specific state or condition of a running virtual machine so that we can troubleshoot a problem.

Standard or production checkpoints in Hyper-V

Before we choose between standard or production checkpoints in Hyper-V let us discuss the two checkpoints. Moving ahead, let us look into the various aspects our Support Engineers introduce to us.

How to change to production or standard checkpoints

1. Initially, in Hyper-V Manager, right-click the virtual machine and click Settings.
2. Under the Management section, select Checkpoints.
3. Then select either production checkpoints or standard checkpoints.
4. To store the checkpoint configuration files in a different place, change them in the Checkpoint File Location section.
5. Finally, click Apply to save the changes. Once done, click OK to close the dialog box.

If we pick production checkpoints, we can also specify whether the host should take a standard checkpoint in case it cannot take a production checkpoint.

Only Production Checkpoints support on guests that run Active Directory Domain Services role (Domain Controller) or Active Directory Lightweight Directory Services role.

What are Hyper-V Checkpoints?

A Hyper-V checkpoint is an unchanging point in the lifespan of a virtual machine. We can use the virtual machine as ordinary, however, the checkpoint is protected from any changes that are made to the virtual machine.

It isolates from nearly anything about a virtual machine that can alter.

The following is a generic description that applies to both standard and production checkpoints.

1. The checkpointing service creates copies of the virtual machine’s configuration files and places them in the virtual machine’s Checkpoint File Location.
2. It creates a differencing disk for every VHD[X] file connecting to the virtual machine.
3. Checkpoint creation ignores pass-through disks entirely.
4. The virtual machine continues to operate from the original configuration files and reads unchanged data from the original VHD[X] file(s).

How To Use Hyper-V Checkpoints as Backups

We cannot use Hyper-V checkpoints as backups. By definition, a backup is a duplication of data. Checkpoints do not duplicate data.

Instead, we can export a checkpoint that is a duplicate of the data and therefore qualifies as a backup.

Nonetheless, checkpoint exports confuse many people. Some think that AVHDX files belong to checkpoints. So, they naturally assume that trading a checkpoint will capture all of the data in the AVHDX. Unfortunately, the premise is incorrect.

The AVHDX does not belong to the checkpoint; it belongs to the active virtual machine. If we export the checkpoint, we get everything up to where the checkpoint was taken, but nothing after.

If we want export occurrences after the checkpoint, then we need to either export the active state of the virtual machine or take another checkpoint and export that.

On the other hand, to get only the changed data, we will need to dig into the API. Since these changes represent raw data blocks, we need basic programming skills.

How to use the Apply, Delete, and Revert Checkpoints Functions

After we create a checkpoint there are three operations that we can use to manage it.

• Apply a Checkpoint

When we “apply” a checkpoint, it becomes the active state of the virtual machine. When we use the GUI to apply a checkpoint, we are given an opportunity to capture the current active state in another checkpoint.

If we decline, the occurrences between the latest checkpoint and the active state of the virtual machine are permanently lost.

Apply has two primary uses:

1. We want to work with the virtual machine as it was when a particular checkpoint was taken. Here, it encourages to take another checkpoint when prompted.
2. We do not like the current state of the virtual machine and would like to use a different state. In this case, the encouragement to take another checkpoint is not as strong.

• Revert a Checkpoint

“Revert” is exactly like “Apply” except:

1. We cannot choose the checkpoint. Revert always applies the most recent checkpoint.
2. We are not given an option to checkpoint the current state. It is permanently lost.

It has one use:

When the immediately preceding checkpoint is where we want to be and we do not care to keep the current state, Revert is superior to Apply.

• Delete a Checkpoint

If we delete a checkpoint, it would destroy the VHDX files, configuration files in \Snapshot.

However, it does literally delete the files in the \Snapshot folder that represent any configuration differences.

“Merge” describes what happens when we “delete” a checkpoint. Data in the source VHDX and AVHDX files combine back into the source VHDX files. No data is deleted.

Difference Between Standard and Production Hyper-V Checkpoints

The hypervisor knows something is going on in the VM because of all the CPU and memory and I/O activity. So, snapshots/checkpoints essentially freeze the virtual machine’s activity at a certain point in time.

Anything that happens after the snapshot does not capture in the snapshot. Because the hypervisor does not know what is happening inside the virtual machine, it just locks these resources as they were at that time. This is a “standard” checkpoint.

The new, “production” checkpoints rely on not-so-recent advances in hypervisor technology. Most, including Hyper-V, now have some technique for reaching into the “black box” and interacting with specially-designed components running inside.

For Hyper-V, these are called “Integration Services” for Windows and “Integration Components” for Linux. One of those services is the Backup service, which in turn interacts with the Volume Shadow Copy Service, which most of us know simply as “VSS”.

VSS is a gateway between backup applications and the operating system. It provides the ability for applications to cease all I/O and flush outstanding data and operations from memory to disk so that the backup does not miss anything.

The most important thing to know about VSS’s is that not all applications take advantage of it. That is where we draw the distinction between “standard” and “production” checkpoints.

Characteristics of Standard Checkpoints

Standard checkpoints capture the active state of the virtual machine’s CPU activity and the active state of the virtual machine’s memory.

In short, the virtual machine exactly as it was when the checkpoint was taken.

Characteristics of Production Checkpoints

Unlike standard checkpoints, production checkpoints do not capture anything else. Instead, they trigger VSS in the guest.

A VSS writer will carry out whatever operations the writer designs it to perform.

For example, Microsoft Exchange will commit its logs to the store. Windows will also stop in-flight I/Os from occurring and flush file system queues.

However, it does not protect Active CPU operations and the memory state in any way.

Use Cases for Standard Checkpoints

A Standard checkpoint is preferable when all of the following are true about an application that we wish to protect in the virtual machine:

• The application is not VSS-aware.
• It actively manipulates data in VHDX by the virtual machine OR performs in-memory operations that must not be lost.
• The application is active when we take the checkpoint.

Use Cases for Production Checkpoints

Similarly, we should choose Production checkpoints over Standard checkpoints when the following conditions apply to the application that we want to protect:

• The application is VSS-aware
• It is passive, operating in a read-only state, or serving data from a remote machine.
• The application stops

A Production checkpoint would be a good choice for an Apache web server that acts as a front-end for a remote SQL server.

Situations to Avoid All Checkpoints

There are some applications whose virtual machines should never be checkpointed:

• Active Directory Domain Servers in multiple domain controller environments.

A Standard checkpoint of a domain controller in a multi-DC environment has the possibility of causing a USN rollback.

If the environment is complex enough to justify multiple domain controllers, then they should not run anything that would justify using Hyper-V checkpoints at all.

• Cluster members.

This restriction applies fairly equally to applications protected by Microsoft Failover Clusters and non-Microsoft clustering technologies. Checkpoints could cause the equivalent of USN rollbacks in those applications.

When these applications synchronize to other members, those other members are not going to bother tracking the status of anything prior to that synchronization point.

If we must checkpoint for some reason, stop the cluster and shut down all other members first.

• Applications with innate replication.

If the application is doing something to synchronize local data with other applications on other servers, it is not a good use for any checkpoints unless we ensure that a reversion does not negatively impact the other members or their data.

When a virtual machine with a Production checkpoint reverts, it is at least aware that something happened. That “something” is generally equivalent to restoring from a full backup.

One benefit for Production checkpoints is that they are smaller for running virtual machines than Standard checkpoints.

Production virtual machines do not need a memory state, so they do not save a copy of it. Standard checkpoints keep an on-disk copy of the exact state of the virtual machine’s memory at the moment of capture.

Configure Checkpoints in Hyper-V 2016

In previous versions, the only thing that we could change is the placement of checkpoint files. In 2016 (including Windows 10 Client Hyper-V), we can:

• Disable checkpoints for a virtual machine entirely.
• Choose between Standard or Production checkpoints.
• Allow a Standard checkpoint to create when a Production checkpoint operation fails.
• Choose where to place a virtual machine’s checkpoint files. However, AVHD[X]s are always in the same location as their VHD[X] parents.

By default, every virtual machine enables for Production checkpoints with the Standard fallback.

To change these settings, open the virtual machine’s settings in Hyper-V Manager and switch to the Checkpoints tab:

We can also use PowerShell, which is ideal for bulk operations. The cmdlet is Set-VM.

The parameter selection for checkpoint type is, easily enough, -CheckpointType. It accepts values of Disabled, Standard, Production, and ProductionOnly.

Use the SnapshotFileLocation parameter to tell it where it places the configuration and state information files.

[Confused with the choice? We’d be happy to assist]

Conclusion

To conclude, we discussed in detail various aspects of standard and production checkpoints. Today, we saw how our Support Engineers choose between Standard or production checkpoints in Hyper-V.