VMware ESXi and vSphere Cluster Management

VMware ESXi Virtual Machine Snapshot Files

Learn how VMware ESXi snapshot files work, including VMDK descriptors, delta disks, VMEM, VMSN, snapshot chains, storage growth, consolidation, and safe troubleshooting.

A VMware ESXi virtual machine snapshot records a point-in-time state so you can temporarily roll back, test changes, apply patches, or validate a configuration. A snapshot is represented by metadata and, for virtual disks, one or more delta disk layers.

Snapshots are useful for short-term operational tasks, but they are not backups. They depend on the original virtual machine disk files and datastore remaining available. For related storage concepts, review browsing VMFS datastores and consolidating snapshots.

What a Snapshot Is—and Is Not

A snapshot preserves a point-in-time view of a VM. After creation, VMware redirects new virtual disk writes to a new delta disk. Existing data remains in the parent disk until later operations merge the layers.

Technology	Purpose	How it differs from a snapshot
Snapshot	Short-term rollback or change validation	Depends on the original disk chain and is unsuitable as an independent recovery copy
Backup	Independent recovery of data or a VM	Normally copies data to separate storage and should be tested independently of snapshots
Replica	Maintains a copy at another location for availability or disaster recovery	Usually provides a separate recovery target rather than a temporary disk layer
Clone	Creates another VM based on an existing VM	Produces a separate VM rather than a temporary rollback layer
Template	Provides a reusable VM image for deployment	Is a provisioning source, not a point-in-time operational rollback mechanism

Common VMware VM and Snapshot Files

File names are common patterns, not universal guarantees. Names and extent layouts vary with datastore type, virtual disk format, ESXi release, and snapshot implementation.

File pattern	Typical purpose	Created or used by snapshots	Important handling note
`.vmx`	VM configuration, including virtual hardware and configured disk references	Used to identify which disk chain the VM is configured to use	Do not infer the active disk from a directory listing alone; inspect configuration and descriptors
`.vmdk`	Small text-based virtual disk descriptor containing extent information and disk metadata	Base and snapshot disks can each have descriptors	Inspect fields such as `parentFileNameHint` read-only; do not routinely edit or delete it
`-flat.vmdk`	Data extent for many traditional VMFS virtual disks	Usually holds the base disk's blocks	It is not normally a standalone disk descriptor
`-00000n.vmdk`	Snapshot delta disk descriptor, such as `-000001.vmdk`	Yes; identifies the delta extent and parent relationship	Do not remove it manually
`-00000n-delta.vmdk`	Data extent containing blocks changed after a snapshot	Yes; grows as the guest writes data	Its size and name do not by themselves prove that deletion is safe
`.vmsd`	Snapshot metadata describing the snapshot inventory and relationships	Yes; supports snapshot management information	A metadata entry can become inconsistent with visible files after interrupted operations
`.vmsn`	Snapshot state information, especially for powered-on or memory snapshots	Often associated with captured VM execution state	Do not delete it manually to remove a snapshot
`.vmem`	VM memory state stored on the datastore	May be created or used when snapshot memory is captured	Can require substantial additional capacity
`.log`	VM diagnostic and runtime logs	Not snapshot disk data, but useful during troubleshooting	Review logs for task, lock, path, and storage errors

VMDK descriptors and extents

A VMDK descriptor is a small text file that tells ESXi how to interpret the disk. It can identify an extent such as a -flat.vmdk or -delta.vmdk, disk format information, and—in a snapshot descriptor—the expected parent.

The parentFileNameHint entry identifies the parent disk filename expected by a child descriptor. VMDK metadata also uses a content identifier, or CID, to help validate parent-child relationships. A mismatch can indicate a broken or inconsistent chain, but should not be corrected by guesswork.

How a Snapshot Disk Chain Works

Important terms are:

Base disk: The original virtual disk on which a snapshot chain is built.
Parent disk: The disk layer referenced by a child.
Child disk: The newer snapshot layer that records later writes.
Delta disk: A layer containing changed blocks after a snapshot point.
Snapshot chain: The ordered parent-child sequence used to present the VM's current disk state.

Suppose a VM starts with app01.vmdk and app01-flat.vmdk. Creating a snapshot commonly produces app01-000001.vmdk and app01-000001-delta.vmdk. New writes go to the first delta. If a requested block exists there, ESXi reads it from the delta. If not, ESXi follows the parent relationship and reads the block from the base disk.

A second snapshot adds another child layer:

app01-flat.vmdk  <-  app01-000001-delta.vmdk  <-  app01-000002-delta.vmdk
     base disk             first child                 newest child
                                                          ^
                                                   new writes go here

A read first checks the newest layer. If that layer does not contain the requested block, the read falls back through its parent, potentially through several layers. Longer chains increase storage management complexity and can contribute to performance overhead. Keep chains short-lived.

Snapshot Creation Choices

Snapshot with or without memory

A disk-only snapshot records disk state without capturing the VM's running memory. A memory snapshot also captures VM memory and execution state, allowing a closer continuation of the running state when reverted. Memory capture requires additional datastore capacity and can take longer, particularly for a VM with a large assigned memory size.

Quiesced snapshots

Quiescing prepares guest filesystems or applications so that pending writes are placed in a more consistent state. VMware Tools and guest operating-system support are important for quiescing. Application consistency also depends on the guest and the application; a quiesced filesystem snapshot is not automatically an application-consistent database backup.

Before relying on quiescing, verify that VMware Tools is installed and healthy, the guest operating system supports the required operation, and the workload's application-consistency requirements are understood.

Storage Consumption and Performance

A delta file grows as the guest changes blocks. Its initial size may be small, but it can approach the size of its parent disk if enough blocks change. Growth depends on:

Guest write rate and snapshot age.
Virtual disk size and the amount of unique data changed.
Patch activity, database writes, temporary files, and other workload behavior.
Backup or replication operations that create or retain snapshots.
The number of snapshot layers and the duration of the chain.

Plan datastore free space before creating a snapshot. Capacity planning must account for possible delta growth and the temporary working space required during consolidation—not merely the initial snapshot size.

Large deltas and lengthy chains can increase I/O work and management complexity. If a datastore becomes full, snapshot growth can stop and the VM may experience write failures or disruption. Monitor snapshot age, count, delta size, and datastore free space continuously.

Snapshot Lifecycle Operations

Operation	Effect on VM state	Effect on disk chain	Capacity and performance consideration	Key caution
Create snapshot	Records a point-in-time disk state, optionally memory and quiesced guest state	Adds a child delta layer for subsequent writes	Delta growth begins immediately; memory capture uses extra space	Record an owner, purpose, and removal time
Revert to snapshot	Returns the VM to the selected point in time	Changes made after that point are discarded from the VM's presented state	May require VM power-state changes and follow-up operations	Confirm that later changes are no longer needed
Delete snapshot	Leaves the VM running on the resulting current state	Commits the appropriate delta data into a parent or retained child layer	Can require substantial I/O and temporary working capacity	Deletion is a merge operation, not file deletion
Delete all snapshots	Removes the snapshot inventory while preserving the VM's current data	Merges the snapshot chain into the remaining disk structure	May be storage-intensive and affect performance	Confirm free space and use a maintenance window
Consolidate	Normally preserves the VM's current state	Commits redundant or outstanding delta layers into parent disks	Requires sufficient space and can generate significant I/O	Investigate failures instead of deleting files manually

Deleting a snapshot does not mean deleting the VM's current data. VMware commits the relevant changes into the remaining chain. This is why deletion can take time and why it can fail when storage capacity, locks, access, or chain integrity are inadequate.

Identifying Snapshot Files Safely

In a datastore browser, look for the VM folder and compare descriptors, extents, timestamps, and sizes. A typical folder may contain:

app01.vmx
app01.vmdk
app01-flat.vmdk
app01-000001.vmdk
app01-000001-delta.vmdk
app01.vmsd
app01.vmsn
app01.vmem
vmware.log

Not every VM has every file. For example, .vmsn and .vmem are associated with memory or powered-on snapshot state, while a disk-only snapshot may not have useful memory-state files.

From an ESXi shell, inspect the directory:

ls -lah /vmfs/volumes/<datastore>/<vm-folder>/

Use this command only to inspect filenames, sizes, and timestamps. To inspect a descriptor read-only:

cat /vmfs/volumes/<datastore>/<vm-folder>/<disk-or-snapshot>.vmdk

Look for extent declarations and parentFileNameHint. To map configured disks, inspect the VM's configuration through vSphere or the VMX references, then follow each descriptor's extent and parent references. A filename alone cannot establish whether a VMDK is active, orphaned, a parent, or safe to remove.

Never manually delete snapshot VMDK descriptors, delta extents, .vmsd, .vmsn, or .vmem files to remove a snapshot. Use Snapshot Manager or another supported VMware management workflow.

Monitoring and Maintenance

Track snapshot age, count, owner, purpose, and planned removal time.
Monitor delta file growth and datastore free capacity.
Review vCenter snapshot alarms and the Snapshot Manager inventory.
Investigate any consolidation needed condition promptly.
Set short retention limits and assign responsibility for every snapshot.
Confirm that backup and replication products clean up snapshots after successful jobs.
Schedule large deletion or consolidation operations during a suitable maintenance window.
Test backups independently; a backup job that temporarily uses a snapshot does not make the snapshot a backup.

You can list registered VMs on an ESXi host with:

vim-cmd vmsvc/getallvms

Then inspect a registered VM's snapshot tree:

vim-cmd vmsvc/snapshot.get <vm-id>

When an approved maintenance process requires removing all snapshots from the command line, the supported command is:

vim-cmd vmsvc/snapshot.removeall <vm-id>

Prefer vSphere Client or vCenter workflows when available. Confirm capacity first and never substitute shell deletion of VMDK or delta files.

Common Failure and Recovery Scenarios

Symptom	Likely cause	Evidence to review	Safe first action	Action to avoid
Consolidation needed warning	Interrupted backup, snapshot, or merge operation left redundant deltas	Snapshot Manager, datastore free space, recent tasks, events, and VM logs	Ensure capacity and use the supported Consolidate operation	Deleting delta files or editing descriptors casually
Snapshot deletion failure	Insufficient space, storage latency, locks, access errors, or a long chain	Task events, available capacity, host and backup activity, chain length	Address the reported operational cause and retry in an appropriate window	Repeatedly retrying without checking capacity or active backup jobs
Low datastore space	High-write workload and an old or retained delta	Snapshot age, delta sizes, workload activity, datastore capacity	Stop further growth where operationally safe and provide capacity before consolidation	Waiting for the datastore to fill completely
Unexpected delta growth	Heavy guest writes, patching, databases, temporary files, or backup activity	Snapshot age, guest workload, write rate, and file timestamps	Remove the snapshot when safe and confirm working capacity	Assuming the original snapshot size predicts final growth
Broken or inaccessible chain	Missing parent, inaccessible extent, broken descriptor reference, lock, or storage problem	All referenced files, descriptor relationships, identifiers, and ESXi or VM logs	Preserve the file set and treat it as a recovery case	Renaming, editing, or deleting files without a validated recovery plan

When the UI and datastore do not match

Compare the VMX disk references, VMDK descriptors, snapshot manager output, datastore contents, and recent task history. An interrupted snapshot or backup operation can leave metadata and visible files temporarily out of alignment. Preserve the existing files before attempting changes, refresh supported inventory views where appropriate, and escalate complex discrepancies rather than removing files.

When a disk is inaccessible

Check whether every referenced parent and child descriptor and extent exists and is accessible. Inspect parent relationships, CID values, locks, paths, and logs in read-only mode. Missing parent disks and inaccessible snapshot chains are data-recovery scenarios. Avoid modifications and use qualified VMware support or recovery expertise.

Operational Best Practices

Use snapshots temporarily for rollback, testing, patching, or change validation.
Document the purpose, owner, creation time, and planned removal time.
Avoid long chains and unnecessary memory snapshots.
Estimate growth from workload write rate and retention duration.
Verify that backup and replication jobs complete snapshot cleanup.
Keep adequate datastore capacity for both continued delta growth and consolidation.
Use supported Snapshot Manager, vCenter, or ESXi management operations.
Test independent backups and recovery procedures instead of relying on snapshots.
Schedule potentially disruptive consolidation activity during a suitable maintenance window.

Key Terms

Consolidation: Committing delta contents into the appropriate parent disk layers.
Quiescing: Preparing guest filesystems or applications for a more consistent snapshot.
Memory snapshot: A snapshot containing VM memory and execution state.
VMFS: VMware's clustered datastore filesystem, commonly used for ESXi VM files.
CBT: Changed Block Tracking, which helps backup software identify changed disk blocks; CBT does not turn snapshots into backups.

Practical Snapshot Workflow

Define the change, owner, rollback point, and expiration time.
Check datastore free space, current snapshots, workload write rate, and backup activity.
In vSphere Client, choose the VM's snapshot action and select memory or guest filesystem quiescing only when required and supported.
Perform the change while monitoring delta growth and datastore capacity.
Validate the result. If rollback is required, revert and confirm which later changes will be lost.
If the change succeeds, delete the snapshot through Snapshot Manager. Allow the merge or consolidation to complete.
Confirm that the snapshot inventory is clean, the datastore has adequate free space, and no consolidation warning remains.

For broader administration practice, see the VMware ESXi online course, vSphere alarms, and cloning a virtual machine.