How to Delete Hyper-V Checkpoints

Checkpoints (formerly known as snapshots) are something like an “undo” button for a virtual machine. As the name suggests, you set a marker at a particular point in time for the virtual machine. If you decide that you don’t like what’s happened to the virtual machine at any point after that, you can go back (revert) to that checkpoint. As we, and a great many others, have gone to great lengths to emphasize, checkpoints are in no way a replacement for backup. Like an actual “undo” button, all of the changes made after the checkpoint are lost if you revert. There is something like a “redo” button; you are given the opportunity to take another checkpoint when you revert to an earlier one. However, no copies of the virtual machine are ever made. Only changes are tracked. Do not attempt to use this feature as a backup tool.

The purpose of this post is to explain how to delete hyper-v checkpoints and what happens when you do so in various conditions. The reasoning behind deleting a checkpoint is straightforward: once you’ve decided that you are happy with the state that a virtual machine is in, or if you have multiple checkpoints and are certain that at least some of them are no longer useful, you can get rid of the unnecessary ones. This post will use a virtual machine with the following checkpoint states as an example:

Checkpoint Example

Checkpoint Example

I’ve renamed them to give them some meaning. We’ll treat this as though we are software developers testing potential patch builds to determine which has the optimal outcome. This configuration is not nearly as complicated as it might at first seem, but it does warranty some explanation. To decipher the tree, start at the root. The checkpoint named “Greenfield” represents the base virtual machine. It is using the original VHDX which is now frozen in time. Some data might be being read from it (particularly the operating system files) but nothing is being written to it. Both the “A” and the “C” branches are completely dormant; none of their files are being used at all. The “B” branch has more activity. Any unique data in checkpoints titled “Patch Branch B”, “Patch B1”, “Patch B2”, and “Patch B3 Variant 1” will be read as necessary. Checkpoint “Patch B3” is completely dormant. All writes are being directed to “Patch B3 Variant 1”.

Simple Checkpoint Deletion

For the sake of this discussion, we’ll say that each checkpoint named “Patch Branch” is nothing but a checkpoint right off of “Greenfield”, and that each of the other checkpoints was taken immediately after the application of the entity it is named after. To illustrate a simple deletion, imagine that it’s been determine that Patch A3 had a flaw and needed to be rebuilt. Rather than correct it in Patch A4, your development team has decided to re-release Patch A3. In that case, it makes sense to simply delete the checkpoint titled “Patch A3” and start over from there. To perform the delete, right-click on the checkpoint and click Delete Checkpoint:

Checkpoint: Simple Delete

Checkpoint: Simple Delete

Because “Patch A3” is in a dormant branch, all files related to that checkpoint will be permanently deleted and that will be the end of it. No other checkpoints or the running state of the virtual machine will be affected. To continue with the scenario outlined in the previous section, you would likely Apply the “Patch A2” checkpoint and then upgrade it with the re-released Patch A3 and then take a new checkpoint.

Branch Checkpoint Deletion

Let’s move on to something a bit more complex. Let’s say that the development team decided that the “C” patch branch was an unmitigated disaster and they just want to forget the whole thing to focus on “A” and “B” branches. To effect that, right-click on the “Patch Branch C” checkpoint and choose “Delete Checkpoint Subtree”:

Checkpoint: Subtree Delete

Checkpoint: Subtree Delete

This action will delete all of the checkpoints and all of their related files from the checkpoint that you chose and all of its child checkpoints. Like the “Patch A3” object, this is in a dormant tree so the running state of the virtual machine is not affected in any way.

Mid-Tree Deletion

Next, you get a call from the software engineering team that says that they are perfectly happy with the testing of Patch B1 and will be adding it to the permanent repository. Technically, you don’t have to do anything. But, this is the actively running branch and each layer of checkpoints impacts performance. However, Patches B2 and B3 are still undecided, so you can’t just delete the entire subtree like you did with the former Patch C branch. Fortunately, it’s not a problem. Just delete “Patch B1” the same way that you deleted “Patch A3”:

Checkpoint: Mid-tree Delete

Checkpoint: Mid-tree Delete

Once this completes, you’ll see that “Patch B2” and both of the “Patch B3” items are still present and unchanged… or are they? The merge operation combined all of its changes back into its parent of “Patch Branch B”, as you likely expected. However, those files were the parents of “Patch B2”. If you check, you’ll find that the parent objects of “Patch B2” are now the files for “Patch Branch B”. The parent chain for the items below “Patch B2” are unchanged. The action that you took has the effect of reducing the overall length of the I/O chain for data reads. However, any difference tracking between the former “Patch Branch B” and “Patch B1” are now lost; “Patch B1” is permanently applied to “Patch Branch B”.

Active Tree Deletion

After some time, the development team contacts you again, saying that they are thrilled with the entire B patch series that you’re working with. Patch B3 Variant 1, which you are currently working with, is better than the original Patch B3, so they just want to get rid of that and end testing of the Patch B branch entirely. To effect this, you could, as before, leave everything alone. But, to improve your performance, you could clean up all of those checkpoints. So, you choose to right-click “Patch Branch B” and click Delete Checkpoint Subtree:

Checkpoint: Delete Active Tree

Checkpoint: Delete Active Tree

This is the outcome:

Checkpoint: Active Tree Deleted

Checkpoint: Active Tree Deleted

Was that a mistake, or was it what you really wanted to do? That depends. Let’s go over what all has happened here. First, anything that happened in the “Patch B3” item is completely lost. Second, all of the changes made in “Patch Branch B”, “Patch Branch B2”, and “Patch Branch B3 Variant 1” are all collapsed into the singular “Now” object. What did not happen is any combining of the “A” branch with the “B” branch, even though there are no longer any objects with the “B” name. The “Now” object and the “Patch Branch A” object exist in the tree at exactly the same level, which means that they are separate, unrelated items. Since you may need to do some more testing with the “A” branch, you might find it wise to create another checkpoint from the level that you’re at now just to keep the “B” branch alive. If you jump to another checkpoint without creating a new checkpoint at this level, the entire branch formerly known as “B” will be lost.

Downstream Checkpoint Deletion

With the successful testing of the “B” branch, the development would like you to return to testing the “A” branch. They’re not sure about A1, so they wanted you to start there again. This is how it looks:

Checkpoint: Downstream Setup

Checkpoint: Downstream Setup

As you test, they discover that A1 had a critical flaw that was then propagated into A2. They don’t want either of these patches to see the light of day. What should you do? This?:

Checkpoint: Delete Downstream Quiz

Checkpoint: Delete Downstream Quiz

If this is what you do, you will not have met the requirements of the development team. This action will discard “Patch A2”. However, it will permanently roll all of the changes from “Patch A1” back into “Patch Branch A” and set that as the running state of the virtual machine. Since the development team wanted you to get rid of Patch A1, that means that the “Patch Branch A” object is useless. In this scenario, you fortunately have the “Greenfield” object to apply, but not everyone remembers to take a checkpoint for that purpose. What you actually want to do is first apply “Patch Branch A” (since you don’t care about keeping anything underneath it, there’s no point in taking another checkpoint when prompted). That will leave you with both “Patch A1” and “Patch A2” as dormant downstream objects. You can now safely delete the subtree from the “Patch A1” level to achieve the stated outcome:

Checkpoint: Delete Downstream Tree

Checkpoint: Delete Downstream Tree

Accepting the Current State — Deleting All Checkpoints

After a strange silence, the head of development calls you. Their department has run out of money. They’ve decided to release the “Patch B” tree. What they were working on for the “Patch A” branch is going to be rebranded as “version 2.0” so they can make money on it, but that will all be done at some point in the future. So, they want you to make the “Patch B” branch permanent and get rid of everything else. As you learned from the previous section, this means that you first need to apply the saved “Patch B” branch so that it is active. Then, just start at the root and Delete Checkpoint Subtree:

Checkpoint: Delete All

Checkpoint: Delete All

A couple of things happen when you delete the root. All checkpoints in the active tree are merged upward into the root. All checkpoint data in all other branches are irrevocably lost. So, before you do this, take care to start at the “Now” object and trace your way upward back to the root to ensure that you really are in the tree that you think that you’re in. If you want to discard all of the changes, apply the root object first and then delete the entire subtree.

Once this operation completes, there will be no checkpoints at all. All read and write activity will occur on the primary VHDX and VM files.

 

Altaro Hyper-V Backup
Share this post

Not a DOJO Member yet?

Join thousands of other IT pros and receive a weekly roundup email with the latest content & updates!

18 thoughts on "How to Delete Hyper-V Checkpoints"

  • Marcello Drewanz says:

    Although the use of checkpoints is a valuable hand on test and development, it is discouraged on production systems – could you confirm and elaborate why ?

    Thanks for the excellent article!

    • Eric Siron says:

      Three reasons to avoid checkpoints in production:

      1. Checkpoints do not interact with VSS in the guest. When you activate a checkpoint, it is possible for some inflight operations or IO to have been lost. Shouldn’t happen, but no guarantees.
      2. People forget about them and let them run until they don’t have enough space for the AVHDX and/or for the merge.
      3. There is an IOPS hit while Hyper-V sorts out whether to retrieve data from a parent VHDX or a child AVHDX. It’s usually not severe unless you have a deep parent-child tree, but it is there.

      This recommendation is kind of old when people didn’t know that much about virtualization and when the earlier VHD was the norm. I know many people that do use them in production. As long as you are aware of the risks, understand that checkpoints are not backups, and keep your real backups up-to-date, I would not be overly concerned about selective use of checkpoints in production.

  • Marcello Drewanz says:

    Although the use of checkpoints is a valuable hand on test and development, it is discouraged on production systems – could you confirm and elaborate why ?

    Thanks for the excellent article!

  • Mark Stringer says:

    Hi,
    Great article, thanks. I have a checkpoint showing in Hyper-V Manager on the primary of a replicated virtual machine. The checkpoint is labelled Backup presumably from our Altaro backup snapshot. The problem is the checkpoint does not actually exist. If I click on it the only options I get are Settings, Export, Raname or Help. I cannot delete it. It is not affecting the normal operation of the VM but it would be good to remove it as it is confusing. Any idea how I might do this or should I log a support call?
    Thanks,
    Mark.

    • Eric Siron says:

      I’ve seen this behavior reported a few times. The backup facilitation system in Hyper-V is tied in with the checkpoint system, so creation of a checkpoint is normal. It sounds like something is not right in your case, though, as the checkpoint should not persist. Log a support call, please.

  • Mark Stringer says:

    Hi,
    Great article, thanks. I have a checkpoint showing in Hyper-V Manager on the primary of a replicated virtual machine. The checkpoint is labelled Backup presumably from our Altaro backup snapshot. The problem is the checkpoint does not actually exist. If I click on it the only options I get are Settings, Export, Raname or Help. I cannot delete it. It is not affecting the normal operation of the VM but it would be good to remove it as it is confusing. Any idea how I might do this or should I log a support call?
    Thanks,
    Mark.

  • Mark Stringer says:

    I saw some interesting behaviour when I recently deleted a VM that I was using as a staging point during an upgrade. The VM had several checkpoints and the Now point was at the end. Having deleted it from Hyper-V manager I went to delete the vhdx files and noticed that the primary vhdx file was growing. The system was removing the checkpoints in the background and consolidating them into the original vhdx file. This caused a lot of disk activity and needed a lot of working disk space (that I had luckily). Is this normal behaviour? If I had tried to delete the vhdx files and avhdx files would it have let me or would they have been locked? Is there a way to prevent this process happening?

    • Eric Siron says:

      I’m missing something in your question, I think. If you delete checkpoints, they are automatically merged into the active VHDX file. You are not to ever delete or modify any of these files yourself. What behavior were you expecting?

      • Mark Stringer says:

        I didn’t delete the checkpoints as such. I deleted the whole VM within Hyper-V manager whilst it still had several checkpoints. This left me with the files on disk which I then went to delete and found they were consolidating automatically. I had not expected this to happen. I just wanted to delete them and was unsure if it would let me since they were in use by a background consolidation process. I decided to wait until they consolidated partly to confirm that was what was happening. I then deleted the remaining vhdx files.

        • Eric Siron says:

          Ah, I see. I missed the part about deleting the source VM.
          The delete process only removes the virtual machine, not the data. The checkpoints are part of the VM but — using admittedly imprecise language — the VHDX is not. So, Hyper-V must merge the AVHDX files back into the VHDX in order to satisfy Goal 1 of deleting the VM (and therefore its checkpoints), and Goal 2 of not deleting the VHDX. Does that make sense?
          If you don’t care about the files, then I suppose it doesn’t matter how you handle it. I think I’d leave allow it to finish just so nothing gets gummed up in the mechanism.

          • Mark Stringer says:

            Thanks. As you say I took the approach of leave it to finish in case I break it by interfering! I’m glad I had enough disk space to have that option. I’ll know in future to apply the base checkpoint and then manually delete the checkpoint subtree first to speed up the process and avoid running out of disk.

  • Gary Braxton says:

    Another thing that you need to understand is that checkpoints are sometimes affected by other servers on your network. Suppose for a moment that you created a checkpoint of a virtualized domain controller before applying a schema extension. Now, imagine that the schema extension was done incorrectly and you need to revert the Active Directory to its previous state.

  • Jason says:

    Hi
    I have a problem where I took over an environment that allowed checkpoints in production and the HDD ran out of space. I copied the checkpoint and primary VHD to another drive, merged the checkpoint and started up the VM. Problem is that I can’t delete the checkpoint from the original drive, I don’t have permission to do it even though I’m the administrator.
    How do I delete the avhdx file?

  • Steve Gwynne says:

    Hi Team
    Hoping you may be able to help. I have a 2012R2 HyperV Server and had to create a Checkpoint on one of the VMS (it only has one checkpoint, this one) as I was wanting to make some changes for testing purposes. I ran into problems so ended up reverting(Applying) it back to its previous state, which worked fine. Now though I still can see the Checkpoint but am not sure whether to delete it as I don’t want to revert back to the Testing Purposes version. Can I just delete that checkpoint or do I need to do something different, as I see the Checpoint avhdx file is starting to grow in size.

Leave a comment or ask a question

Your email address will not be published. Required fields are marked *

Your email address will not be published. Required fields are marked *

Notify me of follow-up replies via email

Yes, I would like to receive new blog posts by email

What is the color of grass?

Please note: If you’re not already a member on the Dojo Forums you will create a new account and receive an activation email.