VMware ESXi and vSphere Cluster Management

Virtual Machine Files in VMware ESXi

Learn where VMware ESXi virtual machine files are stored, what VMX, VMDK, VSWP, snapshot, log, RDM, and suspend files contain, and how their dependencies work.

A VMware ESXi virtual machine is represented by a collection of files, not one single file. These files define the virtual hardware, store virtual disk data, preserve firmware and suspended state, record runtime events, and support features such as snapshots and Raw Device Mapping.

Understanding the files in a VM home directory helps with datastore inspection, troubleshooting, migration, backup validation, and recovery. File names alone are not enough: many files have dependencies, so moving or deleting one file can make the virtual machine unusable.

Where ESXi Stores Virtual Machine Files

An ESXi datastore is a storage location available to an ESXi host. A virtual machine normally has a VM home directory on a datastore. This directory contains the VM's configuration, virtual disks, logs, and optional runtime or snapshot files.

For example, a VM named linux might be stored in a directory such as:

/vmfs/volumes/datastore1/linux/

Administrators can inspect this directory in two common ways:

1. In the vSphere Client, select the datastore, open its datastore browser or files view, and navigate to the VM folder.
2. From an ESXi shell, list the directory and inspect file names, sizes, and timestamps.

ls -lah /vmfs/volumes/<datastore>/<VM_name>/

A graphical datastore view may not make every underlying file obvious. Depending on the client, storage type, disk format, permissions, and presentation of the view, a disk may appear as one logical item even though its implementation uses a small descriptor and a separate backing file. When investigating storage usage or a disk-copy failure, use a complete directory listing and check file sizes.

Core VM Configuration and Firmware Files

The VMX Configuration File

The .vmx file is the virtual machine configuration file. It is a readable text-based definition of the VM's virtual hardware and many of its settings, including virtual CPUs, memory, network adapters, controllers, firmware mode, and references to virtual disks.

A VMX file is not the virtual machine itself. It points to or describes other resources, such as disk descriptor files. Copying only the VMX file does not copy the VM's disks or preserve all of its runtime state.

The NVRAM Firmware File

The .nvram file stores virtual firmware state. This includes BIOS or UEFI settings and, depending on the firmware configuration, boot-related variables. A VM using UEFI may rely on this file for persistent firmware settings.

The NVRAM file is separate from the VMX configuration. The VMX describes the configured virtual hardware, while NVRAM preserves firmware state created or changed during operation.

The VMTX Template File

The .vmtx file is a template configuration file used for virtual machine templates. A template is intended for creating new VMs rather than being operated as an ordinary running VM. Template directories can still contain related disk and supporting files.

Virtual Disk File Structure

A standard VMware virtual disk commonly consists of two cooperating files:

• The VMDK descriptor is a small, text-based .vmdk file containing disk metadata and references to the disk backing.
• The flat VMDK is a -flat.vmdk file containing the virtual disk's actual data blocks.

The descriptor is usually small compared with the flat file. Reading the descriptor can reveal the virtual disk's geometry, provisioning information, adapter-related details, and the name of its backing file.

cat /vmfs/volumes/<datastore>/<VM_name>/<VM_name>.vmdk

Use this command for inspection only during routine administration. Do not manually edit a descriptor unless you are following a supported recovery procedure and understand the consequences.

Default Disk Naming

For a VM named vmhost, the first virtual disk commonly uses:

vmhost.vmdk
vmhost-flat.vmdk

A second disk commonly uses a numbered suffix:

vmhost_1.vmdk
vmhost_1-flat.vmdk

Later disks commonly continue with _2, _3, and so on. The suffix identifies the disk's position in the VM's set of virtual disks; it does not by itself describe capacity or provisioning type.

Memory, Swap, and Suspended-State Files

The VM Swap File

The main VM swap file commonly follows the pattern <VM_name>.vswp. VSWP is disk-backed memory that ESXi can use when it needs to reclaim VM memory under memory contention.

The file's size and presence depend on factors such as the VM's configured memory, memory reservation, and runtime state. A reservation can reduce the amount of VM memory that ESXi needs to back with swap. A powered-on VM can therefore have a swap file even when the guest is not actively experiencing a performance problem.

The VMX Process Swap File

Where applicable, a file matching the pattern vmx-<VM_name>.vswp is associated with swap used by the VMX process. It is separate from the main VM memory swap file and is also related to runtime memory and process state.

Do not treat VSWP files as ordinary temporary files merely because they are not guest-visible disks. Their presence and use are controlled by ESXi and the VM's runtime state.

Suspended State and VMSS

A .vmss file preserves the execution state of a suspended virtual machine. It can contain the information required to resume execution, including the VM's active memory and device state at the time of suspension.

Suspension differs from powering off:

• Suspended: the VM's execution state is saved so operation can resume from that state.
• Powered off: the VM stops without retaining active memory state in a suspend file.

If a VM depends on a VMSS file for resumption, do not remove it before determining whether recovery of the suspended state is required.

VM Runtime Logs

The primary runtime log is vmware.log. It records useful information about power-on and power-off operations, virtual hardware errors, device problems, and guest-related runtime events.

Older rotated logs may also be present, often with numbered or otherwise differentiated names. Historical logs can help correlate a failure with an earlier power cycle or device change.

tail -n 100 /vmfs/volumes/<datastore>/<VM_name>/vmware.log

When a VM will not power on, has a virtual device error, or behaves unexpectedly after a configuration change, review the current log and relevant rotated logs together with the vSphere task and event history.

Snapshot-Related Files

A snapshot preserves a point-in-time view of a VM by changing where subsequent disk writes are recorded. A snapshot is not an independent full copy of every virtual disk. Instead, it creates a dependency chain involving the original base disk, one or more delta disks, and snapshot metadata or state files.

Snapshot Metadata: VMSD

The .vmsd file contains snapshot metadata and inventory information. It helps describe the snapshots associated with the VM and their relationships.

Snapshot State: VMSN

The .vmsn file is a snapshot state file. When a snapshot includes the VM's memory, this file can preserve execution-state information from the time the snapshot was taken. A snapshot that does not capture memory may have less or different state information.

Snapshot Delta Disks

A -delta.vmdk file records changed disk blocks after a snapshot is created. The VM continues to use the base disk for unchanged blocks and the delta disk for blocks changed after the snapshot.

With multiple snapshots, delta disks can form a chain. A later delta can depend on an earlier delta, which in turn depends on the base disk. As the guest changes data, delta files can grow and consume datastore capacity.

Example names may include:

linux.vmsd
linux-SnapshotName.vmsn
linux-000001.vmdk
linux-000001-delta.vmdk

The exact snapshot naming pattern can vary. The key point is that the base disk, snapshot descriptors, delta backings, and metadata must remain consistent.

Raw Device Mapping Files

Raw Device Mapping (RDM) provides a mechanism for mapping a raw storage device to a virtual machine. An RDM mapping file commonly follows the pattern <VM_name>-rdm.vmdk.

The RDM mapping file stores mapping information that allows the VM to access the mapped raw storage device. It is not equivalent to a normal flat VMDK data file: the mapping file does not contain the complete contents of a conventional virtual disk. The actual storage device is the backing resource.

When moving or copying a VM, identify RDM mappings separately from ordinary virtual disks. The mapping file and the raw device have a dependency that must be preserved.

Recognizing a VM Directory

A typical single-disk VM directory might contain files like these:

linux.vmx
linux.nvram
linux.vmdk
linux-flat.vmdk
linux.vswp
vmware.log

A VM with two disks might add:

vmhost_1.vmdk
vmhost_1-flat.vmdk

A directory with snapshots or suspension may also contain VMSD, VMSN, delta, or VMSS files. A template may contain a VMTX configuration file. A VM using an RDM may contain an RDM mapping file.

Files by VM Feature or State

Practical Inspection Examples

Example: Single-Disk VM Named linux

In a simple VM folder, linux.vmdk is normally the small descriptor and linux-flat.vmdk is the much larger file containing the virtual disk's data blocks. The folder may also contain linux.vmx, linux.nvram, linux.vswp while applicable, and vmware.log.

Do not assume that the small VMDK is the entire disk. Inspect the descriptor to identify its backing file, and confirm that the backing file exists.

Example: Two-Disk VM Named vmhost

The first disk commonly uses vmhost.vmdk and vmhost-flat.vmdk. The second uses vmhost_1.vmdk and vmhost_1-flat.vmdk. When inspecting a directory, the numbered suffix is a useful clue that the VM has additional virtual disks.

Example: VM with an Active Snapshot

A snapshot-enabled folder may contain <VM_name>.vmsd, a snapshot-state file such as <VM_name>-SnapshotName.vmsn, and snapshot disk files such as <VM_name>-000001.vmdk with a corresponding <VM_name>-000001-delta.vmdk.

The VM still depends on the base disk. The snapshot delta is not a replacement for the base disk; it records changes relative to the appropriate parent in the chain.

Example: Suspended VM

A suspended VM may have a file such as <VM_name>.vmss. This file is associated with resuming the saved execution state. Do not remove it while the VM is suspended or before confirming that the saved state is no longer needed.

Troubleshooting VM Directory Problems

A VMDK Data File Is Not Obvious

If a datastore browser appears to show only a .vmdk file, use an ESXi shell listing:

ls -lah /vmfs/volumes/<datastore>/<VM_name>/

1. Look for the matching -flat.vmdk file.
2. Compare sizes. The descriptor is generally small, while the backing data file is usually much larger.
3. Read the descriptor to confirm the backing-file reference.

A missing or mismatched pair can cause disk-related errors when the VM is powered on, copied, or moved.

Snapshots Consume Unexpected Datastore Space

Look for .vmsd, .vmsn, snapshot descriptor files, and -delta.vmdk files. Review the snapshot state in vSphere and use supported snapshot removal or consolidation operations.

Delta files can grow as the guest changes disk blocks. Deleting a delta file directly can destroy the snapshot chain and should not be used as a space-reclamation method.

A Suspended VM Cannot Resume

1. Check whether the expected .vmss file is present.
2. Review vmware.log for suspend or resume errors.
3. Confirm that the VM's configuration and disk files are still available.
4. Avoid deleting state files until you determine whether recovery of the suspended state is required.

Moving or Copying a VM Causes Disk Failures

Verify that every VMDK descriptor has its required backing file, including all numbered disk pairs. Check for snapshot chains and preserve every parent-child dependency. Also check for RDM mapping files and confirm that the corresponding raw storage device is available through the destination environment.

Copying only the VMX file, only a descriptor, or only the most recently created delta is insufficient. A VM is a group of related files and storage resources.

Safe Administrative Practices

• Use vSphere workflows for snapshot creation, removal, and consolidation.
• Preserve descriptor and backing-file pairs when copying or moving virtual disks.
• Read descriptor files for investigation, but do not manually edit them during routine administration.
• Do not delete VMSS, VSWP, VMSD, VMSN, or delta files merely because their names appear temporary or unfamiliar.
• Before changing datastore files, identify whether the VM is powered on, suspended, using snapshots, configured as a template, or using an RDM.
• Use file sizes and timestamps together with vSphere inventory and task information; do not infer a file's role from its size alone.

Key Exam and Operations Notes

• A VM home directory contains multiple files, not one monolithic VM file.
• The VMX file describes virtual hardware and settings.
• The NVRAM file preserves virtual BIOS or UEFI state.
• A standard VMDK commonly uses a small descriptor plus a large -flat.vmdk backing file.
• Additional disks commonly use numbered names such as _1 and _2.
• VSWP is ESXi disk-backed memory swap; VMSS preserves suspended execution state.
• VMSD stores snapshot metadata, VMSN can store snapshot execution state, and delta disks store changed blocks.
• Snapshots are dependent chains, not independent full-disk copies.
• An RDM VMDK is a mapping file, not the data file for a conventional virtual disk.
• Manual deletion or renaming of VM files can break dependencies and cause data loss.

For a related reference, see Virtual Machine Files in ESXi.