VMware Cloud Community
VoxMedica
Contributor
Contributor

When does deleting a child snapshot commit the changes AND state to the parent?

I recently took a vSphere 5.0 Fast track course and was confused with what was taught in regards to snapshots.  From the lecture I was told that if i had snapshot tree as such:

  • → Base disk
    • → Snapshot 01 (created folder A)
      • → Snapshot 02 (created folder B)
        • → You Are Here

And deleted Snapshot 02 then Snapshot01 would now contain a state in which both folder A and B existed, such that if i reveted to that state then folder A and B would be present.

  • → Base disk
    • → Snapshot 01 (created folder A& B)
      • → You Are Here

In my testing that was not the case, what i got was

  • → Base disk
    • → Snapshot 01 (created folder A)
      • → You Are Here

So looked over the VMware forums and some tech sites and came to the conclusion that while the changes of a deleted child are committed to the parent the state is not. Meaning that in order to continue to create a base for future snapshots those changes need to be committed, but since that state of those changes is no longer wanted they do not change the state of the parent. The only time that the state and changes are committed is when those changes are committed to the base disk. Is this actually the case?

For further explanation here are the notes i created for myself:

The mechanics of deleting snapshots

When you delete a snapshot it's changes are committed to the parent. So here is an example of a VM snapshot:
   → Base disk
    → Snapshot 01
     → Snapshot 02
      → You Are Here

Example 01
If I delete Snapshot02 then it's changes (NOT THE STATE) will get merged into Snapshot01 and that will be the current snapshot. This is so that future snapshots can build on the changes that were in Snapshot02 and are now currently part of You are Here
   → Base disk
    → Snapshot 01 (STATE) + Snapshot 02 (CHANGES)
     → You Are Here

Example 02
Using the previous example what happens when the last snapshot is deleted? Then all the changes AND states of the previous snapshots are committed to the base disk so that the current state (You Are Here) is the only state.
   → Base disk + Snapshot 01 (CHANGES & STATE) + Snapshot 02 (CHANGES & STATE)
     → You Are Here
  
Example 03
Using the original example if I delete snapshot01 then it's changes AND state will be merged into the Base Disk and Snapshot 02 remains the current snapshot. The reason the changes AND state are changed is because the Base disk is always a parent. So in order to maintain the integrity of all subsequent child snapshots that data must be committed. And since the base disk is never a child it also takes on the state.
   → Base disk + Snapshot 01 (CHANGES & STATE)
    → Snapshot 02
     → You Are Here

Example 04
Now what if Snapshot 01 is current parent and then Snapshot 02 is deleted? Then Snapshot02 is erased along with it's changes. Changes from a deleted child are only committed up the chain from You are here. All snapshots below You are here that are deleted do not have their changes committed because they no longer form the base for any subsequent snapshots.
   → Base disk
    → Snapshot 01
     → You Are Here
      → Snapshot 02

So the final result would be:
   → Base disk
    → Snapshot 01
     → You Are Here

Example 05
A delete all commits all the changes/states to the base disk, but unlike a normal delete operation which commits the changes from child up the to the parent it starts with the base disk (FIFO). Meaning that the very first snapshot is committed, then the child, and then all the remaining children down the chain. Using the base example above the delete all command would consolidate the changes in this order
1. Snapshot01's change/states are consolidated into the Base Disk
2. Snapshot02's change/states are consolidated into the Base Disk
This behavior is new in 4.1 onward. Previous versions would use LIFO, which could exponentially increase disk space usage during a delete all.

Reply
0 Kudos
0 Replies