Snapshot Manager and the backing files
Snapshot Manager is the graphical representation of the virtual machine snapshot database file vm_name.vmsd located in the virtual machine folder.
The VMSD file is a text file organized with schema:
- General entries for Snapshot Manager: snapshot.recordName
- Snapshot specific entries: snapshotX.recordName (where X is an internal number used to identify all entries related to Snapshot X. The first snapshot is noted snapshot0).
The VMSD file includes these entries:
Note: Additional entries are included in the VMSD file but not listed here as it is not relevant for the purpose of this article.
- snapshot.numSnapshots: The number of snapshots in the hierarchy
- snapshot.lastUID: The most recently created snapshot UID = used to ensure there is no duplicate and is incremented by 1, every time a snapshot is created
- snapshot.current: The current snapshot UID = the snapshot from which the virtual machine inherits.
- snapshot.needConsolidate = TRUE: If a consolidation is needed
For each individual snapshot:
- snapshotX: where X is the internal snapshot number.
Note: This number is used to reference the entries related to a specific snapshot and is not used for Snapshot hierarchy.
- snapshotX.uid: The unique Snapshot UID
- snapshotX.displayName: The Snapshot name: displayed is Snapshot Manager
- snapshotX.description: The optional description
- snapshotX.filename: The VMSN file
- snapshotX.numDisks: The number of virtual disks
- snapshotX.diskY.node: The SCSI device ID
- snapshotX.diskY.fileName: The virtual disk filename associated to the SCSI device ID snapshotX.diskY.node
Snapshot Manager shows the snapshot organization but the manipulation of the backing files on the datastore (including but not limited to the virtual disk files) is hidden to the user.
To find the backing files used for each snapshot entry in Snapshot Manager and build a complete list of disk files part of a chain:
- Find the corresponding VMSN and delta disk files for each snapshot by reviewing the VMSD file:
Option 1: Download the file on your local machine and use a text editor.
- Open the datastore browser.
- Open the virtual machine folder.
- Right-click VMSD file and click Download.
- Open the file with a text editor.
Option 2: Edit the file directly on the host using the command line.
- Log in to the ESXi host as root through SSH.
- Change directory to the virtual machine folder and run this command:
cd /vmfs/volumes/DATASTORE_NAME_OR_UUID/VM_FOLDER
- Run this command to open the VMSD file:
cat VM_NAME.vmsd
- Identify the Snapshots as shown in Snapshot Manager. Check the snapshotX.displayName entries.
- Identify that associated VMSN file to snapshotX. Check the snapshotX.filename entry
- Identify the associated backing virtual disks to snapshotX. Check the snapshotX.diskY.fileName entry (or entries with more than one virtual disk).
- Identify the current backing delta disk files that the virtual machine is running from, represented in Snapshot Manager by You are here.
- Edit Settings of the virtual machine, select each Hard Disk and check the disk filename(s).
- Alternatively, review the .vmx file to list all attached virtual disk and look for the present SCSI devices only.
For example, using the command line: cat /vmfs/volumes/DATASTORE_NAME_OR_UUID/VM_FOLDER/VM_NAME.vmx | grep scsi | grep -E "vmdk|present"
- Review the disk chain for each virtual disk found in step 1. and step 2. using the vmkfstools utility:
Run this command vmkfstools -q -v1 against the virtual disks. This operation opens and closes all the disk part of the chain sequentially in the order child > parent
For example:
# vmkfstools -q -v1 "VM_NAME-000004.vmdk"
DISKLIB-VMFS : "./VM_NAME-000004-delta.vmdk" : open successful (23) size = 6610288640, hd = 0. Type 8
DISKLIB-VMFS : "/vmfs/volumes/4f4bdb6e-########-####-########47c/VM_NAME/VM_NAME-000005-delta.vmdk" : open successful (23) size = 65536, hd = 0. Type 8
DISKLIB-VMFS : "/vmfs/volumes/4f4bdb6e-########-####-########847c/VM_NAME/VM_NAME-000003-delta.vmdk" : open successful (23) size = 65536, hd = 0. Type 8
DISKLIB-VMFS : "/vmfs/volumes/4f4bdb6e-########-####-########47c/VM_NAME/VM_NAME-flat.vmdk" : open successful (23) size = 32212254720, hd = 0. Type 3
VM_NAME-000004.vmdk is not an rdm
DISKLIB-VMFS : "./VM_NAME-000004-delta.vmdk " : closed.
DISKLIB-VMFS : "/vmfs/volumes/4f4bdb6e-########-####-########47c/VM_NAME/VM_NAME-000005-delta.vmdk" : closed.
DISKLIB-VMFS : "/vmfs/volumes/4f4bdb6e-########-####-########47c/VM_NAME/VM_NAME-000003-delta.vmdk" : closed.
DISKLIB-VMFS : "/vmfs/volumes/4f4bdb6e-########-####-########47c/VM_NAME/VM_NAME-flat.vmdk" : closed.
In this example:
VM_NAME-000004-delta.vmdk is opened first, followed by VM_NAME-000005-delta.vmdk, followed by VM_NAME-000003-delta.vmdk, and finally VM_NAME-flat.vmdk
Then, all disks are closed in the same order. Represent the hierarchy:
- The parent of VM_NAME-000004-delta.vmdk is VM_NAME-000005-delta.vmdk
- The parent of VM_NAME-000005-delta.vmdk is VM_NAME-000003-delta.vmdk
- The parent of VM_NAME-000003-delta.vmdk is the VM_NAME-flat.vmdk (base disk)
The disk chain manipulation is explained in greater details below. It is important to understand that the numbering of the delta disk files is based on the first available slot number. For example, if a delta disk file VM_NAME-000002.vmdk is already present on disk but VM_NAME-000001.vmdk does not exist, the new created file is named VM_NAME-000001.vmdk. This situation occurs when using the Go To button (API: snapshot.revert)
As a result, the numbering does not necessarily reflect the hierarchy and VM_NAME-000002.vmdk is not necessarily a child of VM_NAME-000001.vmdk:
- VM_NAME-000001.vmdk may be a child of VM_NAME-000002.vmdk.
- VM_NAME-000002.vmdk and VM_NAME-000001.vmdk may not be linked at all and not be part of the same disk chain.
Transformation that occurs when manipulating snapshots
For each snapshot operation in the VMware vSphere Client, the following events and transformation occurs.
Note: The following makes the assumption that the disks are not set to Independent mode. Any virtual disk in Dependent mode is ignored when manipulating snapshots.
Table of Contents</u>
Different types of Buttons for manipulating snapshots:
- Button Take Snapshot:
a. Impact on the virtual disk chain, for each virtual disk (SCSI node):
- A new virtual disk child is created, and the current virtual disk file becomes the parent.
- The virtual machine is now running from the newly created delta disk file.
b. Impact on the VMSD file, for each virtual disk (SCSI node):
- If no VMSD file is present, a new one is created, the snapshotX entries are populated. If this is the first snapshot, X=0. If there are already Snapshots referenced in the VMSD file, X = W+1 (where W is the highest snapshot number).
- snapshot.lastUID is incremented by 1.
- snapshot.current is updated with snapshot.lastUID value.
- snapshot.numSnapshots is incremented by 1.
- The snapshotX.diskY.fileName entry references the current virtual disk filename (CAUTION: This is not the child filename).
- The snapshotX.filename entry references the newly created VMSN file.
c. Impact in the GUI, Snapshot Manager:
- An entry in Snapshot Manager is added and labeled as per snapshotX.displayName.
- The You are here flag is shown as a child of the created snapshot.
- Button Go to/Revert to (vSphere Web Client):
a. Impact on the virtual disk chain, for each virtual disk (SCSI node):
- The current delta disk file is discarded and deleted.
- A new child delta disk file is created from the virtual disk file associated with the snapshot (referenced by snapshotX.diskY.fileName).
- The virtual machine is now running from the newly created delta disk file
b. Impact on the VMSD file:
- The global entry snapshot.current is updated to reflect the snapshotX.uid of the snapshot you want to go to.
c. Impact in the GUI, Snapshot Manager:
- The You are here flag is shown as a child of snapshot you are going.
- Button Delete:
a. Impact on the virtual disk chain, for each virtual disk (SCSI node):
i: If the disk file referenced by the snapshot has only one child disk:
- The child disk file is consolidated with its parent (parent = referenced by the snapshot), then deleted. If the deleted child disk itself had a child disk, then the parent is re-linked with the new child disk.
- If the virtual machine is powered on and if the deleted snapshot is the current one, a new child delta disk file is temporarily created to track the block changes made into the guest while consolidating. This new delta disk file is not referenced by any snapshot entry and is then consolidated with the parent at the end of the process. If the new child delta disk file grows too much during the consolidation, then 1 or more additional iterations may be required resulting in the creation of more temporary delta disk files. At the end of the process, the virtual machine is running from the parent disk file that was associated with the snapshot before deletion (referenced by snapshotX.diskY.fileName).
ii: If the disk file referenced by the snapshot has more than one direct child disk, the parent is still required:
- If the deleted snapshot does not involve the current disk chain, the child disk file is simply deleted
- If the deleted snapshot involves the current disk chain, no change occur
To summarize, deleting a snapshot may result in one of following action on the disk chain:
- Consolidation: Two disk files are merged.
- No action: if the disk file is still required for a subsequent chain.
- Discard: the delta disk file is simply deleted if not required anymore. This action cannot occur if the deleted snapshot is part of the current disk chain
b. Impact on the VMSD file:
- If the deleted snapshot is the current one, snapshot.current entry is updated using the parent Snapshot UID
- The snapshot entries noted snapshotX corresponding to the deleted snapshot are deleted.
- The remaining snapshots entries noted snapshotX are re-numbered to be sequential if the snapshot that has been deleted does not correspond to the highest X value
- The global entry snapshot.numSnapshots is decremented by 1 if snapshot.numSnapshots > 1 or deleted if snapshot.numSnapshots = 1
c. Impact in the UI, Snapshot Manager:
- The snapshot entry is deleted.
- If the deleted snapshot is not the current one, the child snapshots are re-linked as a child of the parent of the deleted snapshot.
- If the deleted snapshot is the current one, The You are here flag is shown as a child of the parent snapshot.
- Button Delete All:
a. Impact on the virtual disk chain, for each virtual disk (SCSI node):
- All delta disk files part of the current disk chain is consolidated with the base disk, then deleted.
- If the virtual machine is powered on, a new child delta disk file is temporarily created to track the block changes made into the guest while consolidating the rest of the chain. This new delta disk file is not referenced by any snapshot entry and is then consolidated with the base disk at the end of the process. If the new child grows too much during the consolidation, then one or more additional iterations may be required resulting in the creation of more temporary delta disk files.
- At the end of the process, the virtual machine is running from the base disk.
- All remaining delta disk files (in other words, part of the non-current disk chain) are discarded and deleted.
b. Impact on the VMSD file:
- The global entries snapshot.numSnapshots and snapshot.current are deleted
- The global entry snapshot.lastUID is untouched
- All snapshot entries noted snapshotX are deleted
c. Impact in the GUI, Snapshot Manager
- All snapshot entries are deleted
- The You are here flag is placed back at the top of the hierarchy. It is shown under the virtual machine name
- Button Consolidate:
- The Consolidate button will only trigger a disk consolidation if the Virtual machine disks consolidation is needed notification is showing in the summary tab for the Virtual Machine (ie, when the snapshot.needConsolidate = TRUE entry is present in the VMSD file).
- The notification appears when a mismatch exists between the snapshot chain and the disk chain. At least one delta disk file is part of a disk chain but cannot be used as a revert point because snapshot manager does not have any reference to it.
- This scenario occurs if a snapshot removal fails due to disk consolidation failure. The snapshot entry is removed from the VMSD file and Snapshot Manager, but the disk consolidation did not complete.
a. Impact on the virtual disk chain, for each virtual disk (SCSI node). The same concepts as removing a snapshot apply (see above) with the following exceptions:
- I: Disk consolidation has to occur (no delta disk file is discarded, and no action is not possible).
- II. More than 2 disk files can be merged.
Note: The Consolidation API is called automatically during a Snapshot Deletion, if necessary, in order to clean up the disk chain.
b. Impact on the VMSD file:
- snapshot.needConsolidate entry is deleted
c. Impact in the GUI, Snapshot Manager:
Example Scenario
To understand the differences, consider this scenario:
Notes:
- Go to: In Snapshot Manager, click the Go to button to revert to a previous state.
- delta1 is the delta file named vm-00001.vmdk, delta2 is the delta file named vm-00002.vmdk
- Take Snapshot #1
- delta1 is created to track changes that occur after Snapshot #1
- The virtual machine is running from delta1 whose parent is the base disk (also known as the flat file)
- Snapshot #1 depends on the base disk
- Take Snapshot #2
- delta2 is created to track changes that occur after Snapshot #2
- The virtual machine is running from delta2, with a parent of delta1, whose parent is the base disk
- Snapshot #2 depends on the delta1 and base disk
- Go To Snapshot #1
- delta2 is discarded.
- delta3 is created, whose parent is the base disk to track changes that occur after going to Snapshot #1
- The virtual machine is running from delta3
- Snapshot #1 still depends on the base disk
- Take Snapshot #3
- A new delta2 is created (same name, but different file from Step 2) to track changes that occur after Snapshot #3
- The virtual machine is running from delta2, with a parent of delta3, whose parent is the base disk
- Snapshot #3 is delta3 and the base disk
Following these steps sequentially results in three snapshots in Snapshot Manager and three delta files that can be simply represented by >:
- > base disk (Snapshot #1)
- > delta3 (Snapshot #3) >> delta2 (current state)
- > delta1 (Snapshot #2)
Note: Snapshot #2 is now an independent chain. It is no longer part of the running virtual machine snapshot chain. Nothing is running from this snapshot or the associated virtual disk delta1, it contains only the changes that were made after Snapshot #1 and before Snapshot #2.
Let us now consider two different scenarios for snapshot deletion:
Scenario #1</u>
In scenario 1, delete Snapshot #1 and then Snapshot #2.
- Delete Snapshot #1
- Snapshot #1 disappears in Snapshot Manager
- No operation on the delta files can be performed. All delta files are required
- The virtual machine is still running from delta2
- Two snapshots in Snapshot Manager (Snapshot #2, Snapshot #3) + three delta files on disk (delta1, delta2, delta3)
- Then delete Snapshot #2
- Snapshot #2 disappears in Snapshot Manager
- delta1 is discarded as there is no longer a dependency
- delta3 is consolidated into its parent, the base disk
- The parent of delta2 becomes the base disk
- Snapshot #3 becomes associated with the base disk
- The virtual machine is still running from delta2
- One snapshot in Snapshot Manager (Snapshot #3) + one delta file on disk (delta2)
The snapshot manager structure now looks like this:
- base disk (Snapshot #3) >> delta2 (current state)
Scenario #2</u>
</u>
In scenario 2, delete snapshot #2.
Delete Snapshot #2
- Snapshot #2 disappears in Snapshot Manager
- delta1 is discarded
- No consolidation occurs, the remaining delta files are required
- The virtual machine is still running from delta2
- Two snapshots in Snapshot Manager (Snapshot #1, Snapshot #3) + two delta files on disk (delta2, delta3)
The snapshot manager structure now looks like this:
- base disk (Snapshot #1) > delta3 (Snapshot #3) >> delta2 (current state)