Although checkpoints have been a key Hyper-V feature since Hyper-V's 1.0 release, Microsoft has always told its...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
customers that Hyper-V checkpoints should not be used in production environments. The reason is that checkpoints have not previously been application aware, and applying a checkpoint can result in data corruption. One of the primary features in Windows Server 2016 Hyper-V, however, is production checkpoints. Production checkpoints leverage Volume Shadow Copy Services to create application-consistent checkpoints. From an application's point of view, applying such a checkpoint is similar to restoring a virtual machine from backup.
A familiar approach to checkpoints
The interface used for creating and managing Hyper-V checkpoints is very similar to that of previous Hyper-V versions. From an administrator's standpoint, it might initially seem as though nothing has changed at all. Although production checkpoints are now the default checkpoint mechanism, checkpoints are created and managed in exactly the same way that they were in the previous version of Hyper-V. There is no obvious visual indicator that differentiates between a production checkpoint and a standard checkpoint. You can see what a production checkpoint looks like in Figure A.
This, of course, raises the question of how an administrator can tell the difference between a production checkpoint and a standard checkpoint and how she can change the checkpoint type. The checkpoint type is controlled at the VM level. As such, there should never be a mixture of production and standard checkpoints within a single VM, although it is possible to mix and match checkpoint types across VMs. In fact, Hyper-V has a mechanism that prevents administrators from changing the checkpoint type if any checkpoints exist. In other words, once an administrator has created a checkpoint, the VM is locked into using that checkpoint type unless the entire checkpoint tree is deleted.
Changing checkpoint types
With that said, it is possible to see what type of checkpoints are being used and to change checkpoint types if no checkpoints currently exist through the Hyper-V Manager. Simply right click on a VM and select the "Checkpoints" option, found in the Management section. As you can see in Figure B, Hyper-V gives you the option to enable or disable checkpoints, change the checkpoint type and change the checkpoint file location.
As you look at the dialog box shown in the figure above, there are two things worth paying attention to. First, you will notice that there is a checkbox used to create standard checkpoints if, for whatever reason, it is not possible to create production checkpoints. This checkbox is selected by default. This checkbox is worth paying attention to because it has its good points and bad points.
On the plus side, selecting this checkbox is good for error prevention. If a condition exists that prevents the creation of a production checkpoint, Hyper-V will automatically revert to using the same tried and true checkpoint mechanism that Hyper-V administrators have been using for years. The disadvantage to selecting this checkbox is, of course, that its use could lead to some unpleasant surprises if a checkpoint is ever applied. Suppose, for instance, an administrator thinks she has been creating production checkpoints, when in reality she has been creating standard checkpoints. Applying such a checkpoint to a production system could have undesirable consequences.
The other item worth acknowledging is the checkpoint file location. Checkpoints should be stored on a high-speed array, so as to minimize the impact they will have on VM performance.
Standard checkpoints still have their place
With production checkpoints being seemingly superior to standard checkpoints, one might wonder why Microsoft didn't just eliminate standard checkpoints. Although I don't have an official statement from Microsoft, there are two reasons why standard checkpoints remain relevant.
First, standard checkpoints can be used in situations in which a production checkpoint may not. For example, a non-Windows VM would likely need to use standard checkpoints.
The other reason standard checkpoints are still useful is because they can be great for troubleshooting. When a standard checkpoint is created, the VM's virtual hard disk and memory contents are preserved as they existed at a point in time. This can be useful when diagnosing an issue or testing potential solutions to an issue.
Production checkpoints are sure to be beneficial for Hyper-V admins. For the first time, Microsoft will support the check pointing of application servers in production environments.
The pros and cons of using Hyper-V checkpoints
Can you recover data after a Hyper-V checkpoint restoration?
Behind the scenes of Hyper-V checkpoints