VMware ESXi and vSphere Cluster Management

VMware ESXi VM Snapshot Files: Types, Roles, and Storage Behavior

Learn what VMware ESXi snapshot files do, how VMDK parent-child chains work, how memory snapshots differ, and how to inspect and safely consolidate snapshot storage.

A VMware virtual machine snapshot records a point-in-time state of a VM. It is not a complete, independent copy of the virtual machine. Snapshot storage usually consists of a disk chain plus metadata and, when selected, memory-state files.

For a complete guide to the file types and chain behavior, see VM snapshot files.

What a VM snapshot captures

A snapshot can capture three kinds of state:

• Virtual disk state: The blocks visible to the guest at the time of the snapshot.
• Virtual machine configuration state: Settings such as virtual hardware configuration and the selected snapshot relationship.
• Optional memory state: The running contents of guest memory when a powered-on snapshot is created with memory capture enabled.

With a disk-only snapshot, VMware preserves the disk state but does not preserve the in-memory state of applications. A later revert therefore returns the disks to the captured point, but it does not restore every running process to its previous execution state.

The exact files created or used depend on whether the VM is powered on, whether memory is captured, the virtual disk format, the datastore type, the VM version, and enabled features such as Changed Block Tracking (CBT).

How the snapshot disk chain works

A base disk is the original virtual disk. A parent disk is the disk referenced by a child disk. A child disk, also called a delta disk, stores blocks changed after a snapshot and refers back to its parent for unchanged blocks.

1. Before a snapshot, the VM normally writes to its base virtual disk.
2. When a snapshot is created, the base disk becomes the parent reference point for the active chain.
3. New guest writes are redirected to a new child delta disk instead of overwriting the parent.
4. Reads use the newest child first. If a block is not present there, VMware follows the parent references until it finds the required block.
5. A later snapshot creates another child. The chain can then look like base disk → snapshot 1 delta → snapshot 2 delta.

Long or deep chains increase metadata lookups, commit work, storage latency, and the chance that an operational problem will affect multiple dependent files. Snapshots should therefore be short-lived and limited according to the supported VMware product-version guidance.

Snapshot operations are different

• Create: Starts a new child delta disk and records snapshot metadata.
• Revert: Returns the VM to the selected snapshot state. Changes made after that point can be discarded, or a new branch can be retained depending on the operation and interface choices.
• Delete snapshot: Commits changed blocks from the snapshot into its parent and removes that snapshot from the active chain. It is not simply a file deletion.
• Delete all: Commits and removes the snapshots in the chain, potentially creating substantial storage and I/O work.
• Consolidate: Merges residual or uncommitted delta data into the appropriate parent when the VM has leftover snapshot files or reports that consolidation is needed.

Base virtual disk files

The original virtual disk commonly has a small text-based descriptor ending in .vmdk. On VMFS, its bulk data is often stored in a separate extent with a name such as VMName-flat.vmdk. Other provisioning modes and datastore types can use different backing formats or storage objects.

The base descriptor contains information that identifies the disk format and its extent. The base disk remains a parent reference point for snapshot disks. Do not manually rename, move, or delete the base descriptor or extent while snapshots exist.

Snapshot delta disk files

Common ESXi naming patterns include:

• VMName-000001.vmdk — the snapshot disk descriptor.
• VMName-000001-delta.vmdk — the associated snapshot data extent.
• VMName-000002.vmdk and VMName-000002-delta.vmdk — another snapshot level in the chain.

The numbered .vmdk file is usually a small descriptor, not the bulk disk data. The delta extent stores changed blocks. It grows as the guest changes data and can approach the logical size of its parent disk, although actual consumption depends on changed blocks, provisioning, and storage behavior.

Numbers such as -000001 and -000002 indicate a naming sequence, not the current disk size. A higher number does not, by itself, prove that the file is newer, larger, or the active end of the chain. Inspect the descriptors and the VM inventory.

VMDK descriptor files

A VMDK descriptor is a small text file containing virtual disk metadata. Depending on the disk and platform, it can describe:

• Disk geometry and virtual capacity.
• Provisioning and compatibility format.
• Extent locations and extent types.
• The parent disk for a snapshot child.
• Change tracking information where applicable.
• Content identifiers used when checking chain relationships.

A snapshot descriptor can contain a setting such as parentFileNameHint, which identifies the parent disk. Its extent section identifies the associated delta data file. These references form the disk chain independently of what a filename pattern might suggest. An incorrect parent reference or missing descriptor can make the virtual disk inaccessible.

Snapshot metadata and inventory files

The .vmsd file stores snapshot metadata used by snapshot-manager features, including information about snapshot relationships and inventory presentation. It is different from the VMDK parent-child chain and is not the only source of truth for disk relationships.

The VM configuration file, usually VMName.vmx, identifies the VM's hardware and configuration, including the virtual disk currently attached to a virtual controller. VMDK descriptors define how those disks are assembled. The .vmsd file supports snapshot inventory and metadata. These files work together but have different roles.

Snapshot-related files can remain in a VM directory even when the vSphere Client shows no active snapshot. Possible explanations include residual deltas after an interrupted operation, a chain still referenced by configuration, stale metadata, or files left by a previous workflow. Never decide that a file is safe to remove from its name alone.

Memory-state and suspend-state files

A powered-on snapshot can optionally include the VM's memory state. This allows a revert to resume the VM closer to its captured execution state, including in-memory application state. Capturing memory can take longer and consume substantial datastore capacity, potentially related to the VM's configured memory size and platform behavior.

.vmsn files are snapshot state files associated with VM snapshot state and, when selected, memory-state capture. A .vmem file may also be encountered as VM memory backing or memory-state-related storage. Its presence and exact role depend on VM state and platform behavior.

A disk-only snapshot does not preserve running memory. For example, if an application has unsaved data in RAM, reverting a disk-only snapshot restores the disk view but does not restore that in-memory data.

VM snapshot file reference

Snapshot lifecycle example

Disk-only snapshot of a powered-on VM

Suppose a VM uses a base descriptor and base extent. A disk-only snapshot creates a numbered descriptor and delta extent. The base becomes the parent, and new guest writes go to the delta. If the VM is later reverted, its disk view returns to the snapshot point, but its running memory is not restored.

Snapshot that includes memory

The same disk chain is created, but snapshot state and memory-related files can also be created or expanded. The operation consumes more capacity and may take longer. Reverting can restore the guest closer to its captured running state.

Two snapshots over several days

After snapshot 1, the chain is base → snapshot-1 delta. After snapshot 2, it becomes base → snapshot-1 delta → snapshot-2 delta. New writes normally go to the newest child. Deleting the oldest snapshot requires committing its changed blocks into the next disk in the chain rather than simply removing the oldest file.

Snapshot capacity planning

Snapshots are change-dependent, expanding checkpoints rather than fixed-size copies. Monitor:

• Datastore free capacity.
• Snapshot age and ownership.
• Delta growth rate and guest write activity.
• Depth of the snapshot chain.
• Active delete, commit, and consolidation tasks.
• Memory-state files for powered-on memory-inclusive snapshots.

A heavily written VM can fill a delta quickly. Delete and consolidate operations also need working free space because changed blocks must be committed while the VM continues to operate. Low capacity can cause failed operations, performance degradation, or broader datastore problems. Do not wait until a datastore is nearly full.

Snapshots are intended for short-term operational use, not long-term retention or backup. Follow the supported snapshot chain limits and product-version guidance for the deployed vSphere and ESXi release rather than assuming that an unlimited number of snapshots is safe.

Inspecting snapshot files safely

Using the vSphere Client

1. Open the VM's Snapshots view and review the visible snapshot tree.
2. Check snapshot names, creation times, descriptions, and recent tasks or events.
3. Open the VM hardware configuration and identify the virtual disk currently attached to each controller.
4. Use the datastore file browser to inspect directory contents and file sizes.
5. If the VM reports that consolidation is needed, verify capacity and tasks before using the supported Consolidate action.

The datastore browser is an inspection and inventory tool in this context. It is not a substitute for supported snapshot operations.

Reading a descriptor from ESXi Shell or SSH

When authorized, inspect the small descriptor as text. Do not open the large extent as though it were a text descriptor.

ls -lah /vmfs/volumes/<datastore>/<vm-directory>/
cat /vmfs/volumes/<datastore>/<vm-directory>/<snapshot-disk>.vmdk
grep -E 'parentFileNameHint|RW|extent|CID|parentCID' /vmfs/volumes/<datastore>/<vm-directory>/<snapshot-disk>.vmdk

Look for the extent reference, parentFileNameHint, content identifiers, and parent identifiers. Use these commands for observation and documentation unless following an approved recovery procedure.

Get-VM | Get-Snapshot | Select-Object VM,Name,Created,SizeMB,Description
Get-VM | Where-Object { $_.ExtensionData.Runtime.ConsolidationNeeded } | Select-Object Name

PowerCLI snapshot size values can be estimates. Evaluate them alongside datastore free space, actual file growth, and current write activity.

Troubleshooting snapshot storage

Consolidation is needed

Residual delta disks can remain after an interrupted snapshot commit or failed operation. Verify visible snapshots, datastore free space, recent tasks, and VM events. Run the supported Consolidate operation when conditions permit. If consolidation fails or descriptors appear inconsistent, preserve the files and escalate through a documented recovery process or VMware support.

Datastore usage grows rapidly

Likely causes include high guest write activity, a memory-inclusive snapshot, or snapshots retained longer than intended. Measure free capacity, identify the snapshot age and change rate, and schedule supported deletion or consolidation before capacity becomes critical.

A descriptor exists but its delta extent is missing

This can result from accidental deletion, an incomplete storage operation, or chain corruption. Do not power on or alter the VM without assessing the chain. Preserve existing files, collect descriptor references and task history, and use a documented recovery process or vendor support.

No snapshots appear in the manager, but numbered files remain

Check whether the VM configuration references a snapshot disk and whether the VM reports consolidation needed. Inspect descriptors read-only. The files may be residual, or they may belong to a chain that is not obvious from filenames. Use supported consolidation or recovery procedures instead of deleting them.

Snapshot deletion is slow

Large deltas, high guest write activity, deep chains, and constrained datastore performance can make deletion or consolidation lengthy. When possible, allow the commit task to complete while monitoring capacity, latency, and task progress. Avoid interrupting the operation or manually removing files.

Files and features commonly confused with snapshots

Exam-relevant summary

• A snapshot is a point-in-time record, not an independent backup or full VM copy.
• The base disk becomes the parent, while new writes go to a child delta disk.
• The numbered snapshot .vmdk is generally a descriptor; the -delta.vmdk file contains the changed disk blocks.
• .vmsd provides snapshot-manager metadata, while VMDK descriptors define the actual disk chain.
• .vmsn and possible .vmem files relate to snapshot or memory state; they are distinct from disk deltas.
• Delete and consolidate operations commit changed blocks and need adequate free space.
• CBT .ctk files are backup-related change tracking data, not snapshot deltas.
• Never manually delete or edit suspected snapshot files during routine administration.