Checkpoints provide a convenient way to revert a VM to a prior state. Referencin

Question

Checkpoints provide a convenient way to revert a VM to a prior state. Referencing Chapter 5 Using Checkpoints and/or internet resources perform the following: a. Explain the difference between Standard and Production checkpoints in Hyper-V 2016. b. Demonstrate the key differences between Standard and Production checkpoints. You must demonstrate both types of checkpoints. Include screen-shots to substantiate your points. c. Describe a good scenario for when to use a Standard checkpoint and when to use a Production checkpoint.

Explanation / Answer

Production checkpoints are "point in time" images of a virtual machine, which can be restored later on in a way that is completely supported for all production workloads. This is achieved by using backup technology inside the guest to create the checkpoint, instead of using saved state technology.

Standard checkpoints capture the state, data, and hardware configuration of a running virtual machine and are intended for use in development and test scenarios. Standard checkpoints can be useful if you need to recreate a specific state or condition of a running virtual machine so that you can troubleshoot a problem.

Characteristics of Standard Checkpoints?
Start with the initial “What are Checkpoints” section. Everything there applies to standard checkpoints. Additionally, standard checkpoints capture:

The active state of the virtual machine’s CPU activity
The active state of the virtual machine’s memory
The short form definition of a standard checkpoint is: the virtual machine exactly as it was when the checkpoint was taken.

Characteristics of Production Checkpoints?
Start with the initial “What are Checkpoints” section. Everything there applies to production checkpoints. Unlike standard checkpoints, production checkpoints do not capture anything else. Instead, they trigger VSS in the guest. Any application operating within that has registered a VSS writer will then carry out whatever operations the writer is designed 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.

What’s important to know is that active CPU operations and the memory state are not protected in any way.

When Should I Use Checkpoints?
Checkpoints should be used for short-term protection during a planned event that might cause otherwise irreparable damage to a virtual machine. This is true for both Standard and Production checkpoints. Examples of valid usages for checkpoints:

A not-particularly-trustworthy vendor wants to upgrade their application. You want to see that application functioning properly in your environment before you permanently commit.
Microsoft/Windows Updates, especially on systems that have been seriously broken by previous updates.
Systems used to test in-development applications that make system-level changes.
Whatever reason you have for using a checkpoint, they are for short-term usage only. I’ve heard of people allowing checkpoints to sit for as long as a year before deciding to do anything about it. Even if they can address the situation without problems, that’s not a good usage of the technology. Personally, I don’t like checkpoints to live for more than a few hours. I suppose a deeply layered upgrade process might warrant a checkpoint that lives for a day or two. I can’t give you a hard rule, but I can give you a solid rule of thumb: never allow a checkpoint to outlive its usefulness. What I mean is, for every checkpoint that you’ve got, ask yourself: “If I revert this checkpoint, would the state of the virtual machine be useful, or would I lose too much?” If it’s not useful, merge it now.

Should I Use Standard or Production Checkpoints?
Do not allow the term “Production Checkpoint” to imply that Standard checkpoints cannot be used in production. Standard checkpoints have always been supported in production environments. There are some cases in which they will still be the preferred option.

Use Cases for Standard Checkpoints
I’m assuming that my Notepad demonstration is not indicative of normal server operations. However, there are a great many server-based applications that don’t respond to a VSS event. A Standard checkpoint is preferable to a Production checkpoint when all of the following are true about an application that you wish to protect in the virtual machine:

The application is not VSS-aware.
The application actively manipulates data in VHDX owned by the virtual machine OR performs in-memory operations that must not be lost if it can be avoided. This does not apply to in-memory operations against data on remote servers, because the state of data on a reverted virtual machine will not be synchronized to any remote server.
The application is active (running) when the checkpoint is taken.
Examples of this type of application would be non-VSS-aware database and mail servers. I have worked with many vendors that use very old database technology (read as: the application vendors and their customers can avoid licensing fees for modern RDBMSs). These would best be served by standard checkpoints.

Use Cases for Production Checkpoints
Production checkpoints are generally best used any time that any one of the conditions that call for Standard checkpoints are not true. Let’s specify them outright. Choose Production checkpoints over Standard checkpoints when any of the conditions apply to the application that you want to protect:

The application is VSS-aware
The application is passive, operating in a read-only state, or serving data from a remote machine.
The application is stopped
There are many obvious uses for Production checkpoints, so I’ll skip those. A Production checkpoint would be a good choice for something like an Apache web server that acts as a front-end for a remote SQL server. If reverted, the Apache web server will resume from an Off state, so it won’t attempt to continue any operations that were active when the checkpoint was taken. If you used a Standard checkpoint instead and a web user was trying to update a record, that could result in some data inconsistency.

Are There Any Situations in Which All Checkpoints Should be Avoided?
I clearly do not subscribe to the “never” philosophy of checkpoints. However, there are some applications whose virtual machines should never be checkpointed:

Active Directory Domain Servers in a multiple domain controller environment. A Standard checkpoint of a domain controller in a multi-DC environment has the possibility of causing a USN rollback. Domain controllers running Windows Server 2012 or later should be immune, but USN rollbacks can be so devastating that the risk isn’t worth it. You should also technically be safe if using a Production checkpoint, but again, it’s probably not worth it. If your environment is complex enough to justify multiple domain controllers, then they should not be running anything that would justify using Hyper-V checkpoints at all. Environments with a single domain controller cannot encounter a USN rollback, but I still do not see a valid use case for checkpoints in that case, either.
Cluster members. This restriction equally 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 aren’t going to bother tracking the status of anything prior to that synchronization point. If you revert a member to a checkpoint, it won’t know what it doesn’t know, and the other members won’t understand why it doesn’t know. If you must checkpoint for some reason, stop the cluster and shut down all other members first. This has some exceptions when the cluster members are just front-ending for data and not keeping anything locally, but you must have a solid understanding of data flow in these applications.
Applications with innate replication. I think we’re building a pattern here. If your application is doing something to synchronize local data with other applications on other servers, it’s not a good use for any checkpoints unless you ensure that a reversion does not negatively impact the other members or their data.
Production checkpoints can address some of these issues. When a virtual machine with a Production checkpoint is reverted, it is at least aware that something happened. That “something” is generally equivalent to being restored from a full backup. If you understand how your application will react in that case, then you understand how it will react to the application of a Production checkpoint.

One benefit for Production checkpoints is that they are smaller for running virtual machines than Standard checkpoints. Production virtual machines don’t need memory state, so they don’t 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.

Related Questions

Navigate

• Browse (All)
• Browse C
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.