VMX vs VMDK: VMware File Roles, Structure, and Recovery — VMDK vs VMX and VMware VMX vs VMDK VMware Explained

In VMware, two files define every virtual machine: the VMX and the VMDK. The VMX file is a small text configuration file that stores the VM’s hardware settings — CPUs, memory, NICs, and disk mappings. The VMDK file is the virtual disk itself, containing the operating system, applications, and user data. Lose the VMX and the VM cannot start; lose the VMDK and the VM has no data to run. This article explains the differences between VMX and VMDK files, their roles in VMware environments, and how to recover them when they are deleted, corrupted, or locked.

What Is a VMDK File? The Virtual Disk Core of VMware VMs

VMDK File Definition and Purpose

The VMDK file is the virtual disk of a VMware VM. It stores the guest operating system, installed applications, and all user data. While the VMX defines how the VM runs, the VMDK defines what the VM runs. Without a valid VMDK, a VM can power on but has no usable storage or OS to boot from.

What a VMDK File Contains

A VMDK file includes:

• Guest OS installation (Windows, Linux, BSD, etc.)
• Application binaries and configuration files
• User data such as documents, databases, and logs
• Swap/paging files used by the guest OS
• Snapshot delta chains that track incremental changes to the base disk
• Metadata descriptors defining disk geometry, block size, and allocation type

VMDK File Format: Descriptor + Flat Disk

Every VMDK is composed of two parts:

• Descriptor file (.vmdk) — a small text file describing disk size, geometry, provisioning type (thin/thick), and references to the actual data file.
• Flat or sparse disk file — the large binary file that contains the VM’s data blocks.
  When snapshots are taken, VMware creates additional delta VMDKs that chain back to the base disk, allowing rollback or point‑in‑time recovery.

VMDK File Naming and Location

VMDK files reside in the same VM directory as the VMX file:
/vmfs/volumes/[datastore]/[VMname]/[VMname].vmdk
Large disks may split into multiple files, such as VMname-flat.vmdk or VMname-s001.vmdk. Sizes range from a few MB for test VMs to multiple TB for production workloads.

Operational Importance

• VMX vs VMDK: The VMX is the brain (configuration), while the VMDK is the body (data). Losing the VMX prevents startup; losing the VMDK destroys the VM’s content.
• Recovery priority: If both are lost, recovering the VMDK is usually more critical, since it contains irreplaceable user and application data. The VMX can often be rebuilt manually, but the VMDK must be restored from backup or specialized recovery tools.

What Is a VMDK File? The Virtual Hard Drive of a VMware VM

VMDK File Definition and Purpose

A VMDK (Virtual Machine Disk Format) file is the virtual hard drive of a VMware VM. It contains the operating system, application binaries, configuration files, and all user data — essentially everything that would reside on a physical disk. The VMDK is typically the largest file in a VM’s directory, sized to match the virtual disk allocation defined in the VMX. Without it, the VM has no storage to boot from or run workloads.

The Two‑File VMDK Structure: Descriptor and Flat

Every VMDK on ESXi consists of two paired files:

• VMname.vmdk — Descriptor file: A small, text‑based file that defines disk geometry, size, and provisioning type (thin, thick eager‑zeroed, thick lazy‑zeroed). It points to the backing flat file. This is where confusion often arises in the vmdk vs vmx file discussion: the descriptor .vmdk is text‑based like a VMX file, but its role is disk metadata, not VM configuration.
• VMname‑flat.vmdk — Flat file: A large binary file containing the raw disk data. This is where the VM’s OS, applications, and user data live. On ESXi, the flat file matches the size of the allocated virtual disk.

VMDK Provisioning Types

VMware supports three provisioning modes for VMDKs:

• Thin provisioning: Disk space is allocated on demand as data is written. Starts small and grows up to the defined maximum. Ideal for storage efficiency.
• Thick lazy‑zeroed: Full disk space is reserved at creation, but blocks are zeroed only when first written. Faster to create, moderate performance.
• Thick eager‑zeroed: Full disk space is reserved and zeroed at creation. Provides the best write performance but takes longest to provision. Required for VMware Fault Tolerance.

VMDK Variants: Snapshots, Split Disks, and RDMs

• Snapshot VMDKs (VMname‑000001.vmdk): Delta files created when a snapshot is taken. The base disk becomes read‑only, and all writes go to the delta. Multiple snapshots create chains of delta VMDKs.
• Split VMDKs: Disks divided into 2 GB chunks (VMname‑s001.vmdk, VMname‑s002.vmdk). Common in VMware Workstation for file system compatibility; rare on ESXi unless imported.
• RDM (Raw Device Mapping): A special VMDK descriptor that maps a SAN LUN directly to the VM, bypassing VMFS for near‑native performance. Used in advanced storage scenarios.

VMware VMX vs VMDK VMware: The Complete VM Directory — All Supporting File Types

📊 Full VMware VM Directory: File Types Reference Table

What Happens When VMX or VMDK Files Are Lost, Corrupted, or Deleted

Corrupted VMX: Symptoms and Immediate Impact

A corrupted or missing VMX file causes the VM to disappear from vSphere inventory. The VM cannot register or power on because ESXi has no configuration blueprint to follow. Typical error messages include:

• “The file specified is not a virtual disk”
• “Unable to access file”

Despite these errors, the VMDK and all user data remain intact on the datastore. The damage is limited to configuration loss. Administrators can often rebuild the VMX by creating a new VM with identical settings and pointing it to the existing VMDK.

Corrupted or Deleted VMDK: The Data Loss Scenario

A missing or corrupted VMDK flat file is a true data loss event. Even if the VMX is intact, the VM cannot boot because the guest OS has no disk to load. Common causes include:

• Accidental deletion from the datastore browser
• Failed storage migration or vMotion
• Snapshot chain corruption (parent VMDK modified after a child delta was created)
• VMFS datastore going offline due to storage controller failure
• LUN reassignment breaking datastore paths

In these cases, recovery requires restoring the VMDK from backup or using specialized VMFS recovery tools.

Snapshot Chain Corruption: The VMX and VMDK Intersection

One of the most disruptive scenarios occurs at the VMX–VMDK boundary during snapshot operations. When creating a new VM and selecting an existing VMDK, the wizard only presents the base VMDK — not the snapshot delta files. If a VM with active snapshots has its VMX rebuilt without accounting for the full snapshot chain, the delta VMDKs become disconnected.

The result is the error:
“The parent virtual disk has been modified since the child was created.”

Here, the base VMDK appears intact, but the snapshot chain is broken. All data written since the last base snapshot becomes inaccessible unless targeted recovery is performed. This highlights how VMX and VMDK files are interdependent: the VMX must correctly reference the snapshot hierarchy, and the VMDKs must remain consistent to preserve data integrity.

Recovering VMX and VMDK Files with DiskInternals VMFS Recovery™

Why Standard Recovery Tools Fail on VMFS

VMFS (VMware File System) is VMware’s proprietary clustered filesystem. Unlike NTFS, ext4, or FAT32, VMFS uses unique metadata structures to manage multi‑host access and virtual disk chains. Standard recovery tools cannot parse VMFS layouts, interpret VMDK descriptor files, or reconstruct snapshot hierarchies. As a result, attempting recovery with generic tools often produces incomplete or unusable files. Effective recovery of VMX or VMDK files from a damaged or offline VMFS datastore requires a solution purpose‑built for VMware environments.

DiskInternals VMFS Recovery™: Purpose‑Built for VMware File Recovery

DiskInternals VMFS Recovery™ is designed specifically to handle VMware file recovery scenarios. Its capabilities include:

• Mounting VMDK files without ESXi — critical when the hypervisor is unavailable and only raw storage remains.
• Recovering deleted VMX configuration files — restoring VM registration and startup capability.
• Reconstructing VMFS volumes with damaged metadata — rebuilding access paths to VM files.
• Supporting both local and remote recovery — works with locally attached VMware disks or remote ESXi servers via IP and credentials.

Workflow:

1. 1. Connect to the VMFS volume.
2. 2. Run a full scan to detect recoverable VMX, VMDK, and supporting files.
3. 3. Browse the results and preview file integrity.
4. 4. Extract recovered files to a safe destination.
5. 5. Re‑register the VM in vSphere using the restored VMX and VMDK.

When to Use DiskInternals VMFS Recovery™

VMFS Recovery is applicable in scenarios such as:

• Accidental deletion of a VMDK from the datastore browser.
• VMFS volume going offline after storage controller failure or LUN reassignment.
• ESXi host crash leaving stale lock files that block VM startup.
• VMX corruption or deletion causing a VM to vanish from inventory.
• Snapshot chain breakage making delta VMDKs inaccessible.
• Failed migration between ESXi versions or from ESXi to KVM leaving orphaned VMDK files.

In all these cases, the flat VMDK data typically survives on disk. The challenge is accessing it — and the path to recovery is a tool that speaks VMFS natively.

Practical Administration: Working with VMX and VMDK Files

Rebuilding a Lost VMX File Without Data Loss

Step‑by‑step process:

1. 1. Remove the damaged VM from vCenter inventory (important: do not delete files from datastore).
2. 2. Launch the New Virtual Machine Wizard and select Use an existing virtual disk.
3. 3. Point to the intact VMDK descriptor file to attach the existing virtual disk.
4. 4. Reconfigure hardware settings to match the original VM — CPU, memory, NICs, hardware version.
5. 5. Complete the wizard; ESXi generates a new VMX file automatically.
6. 6. Register the VM and verify it powers on correctly.

Throughout this process, the VMDK data remains untouched — only the VMX is rebuilt.

Editing a VMX File Safely: Rules and Best Practices

• Always power off the VM before editing the VMX directly.
• Make a backup copy of the VMX before any manual change.
• Edit only parameters you fully understand — incorrect entries can prevent VM registration.
• After editing, either re‑add the VM to inventory or respond to the Reload VM Configuration prompt if ESXi detects changes.
• Automate VMX backups: a daily compressed archive of all VMX files across an ESXi host takes seconds and provides instant recovery for configuration loss.

Converting and Migrating VMDK Files

Use VMware Converter or vmkfstools (ESXi CLI) to:

• Convert between thin and thick provisioning.
• Upgrade disk versions for hardware compatibility.
• Export to OVA/OVF for cross‑platform migration.

For KVM environments, use qemu‑img convert to import VMware VMDKs.

Always verify the descriptor file after migration — ensure path references and provisioning type match the new environment.

A mismatched descriptor is a common cause of “Not a virtual disk” errors after migration.

FAQ