VMware ESXi and vSphere Cluster Management

VMware Workstation Player Virtual Machine Files: Purpose, Locations, and Safe Management

Learn what VMware Workstation Player VM files do, where they are stored, and how to safely inspect, copy, back up, migrate, and troubleshoot them.

A VMware virtual machine (VM) is not a single file. On the host operating system—the operating system of the physical computer—VMware stores the VM as a folder containing configuration, virtual hardware state, virtual disks, memory-related data, logs, and sometimes suspend or snapshot files.

The operating system installed inside that VM is the guest operating system. Its applications, partitions, filesystem, and personal files are stored in the VM's virtual disk, usually represented by one or more .vmdk files.

File names commonly begin with the VM name. For example, a VM named Ubuntu-Lab might contain Ubuntu-Lab.vmx, Ubuntu-Lab.nvram, and Ubuntu-Lab.vmdk. The extension identifies the file's role. Related files must normally remain together, especially when a VM is copied, moved, or backed up.

Finding the virtual machine directory

In VMware Workstation Player, select the VM in the library and open its virtual machine settings. The settings and library information identify the VM's configured location. You can also use the settings for individual virtual devices, such as the virtual disk, to see the paths VMware is using.

Common default locations vary by version and installation choices. On Windows hosts, VMs are often stored below the user's Documents\Virtual Machines folder. On Linux hosts, a common location is a vmware folder below the user's home directory. These are only defaults: a VM may be stored on another local drive, an external drive, or a custom directory.

A conceptual VM folder

The following listing is illustrative. Not every VM contains every file, and file names can vary with VMware version, disk layout, power state, and product edition.

Ubuntu-Lab/
├── Ubuntu-Lab.vmx
├── Ubuntu-Lab.nvram
├── Ubuntu-Lab.vmdk
├── Ubuntu-Lab-flat.vmdk
├── Ubuntu-Lab.vmem
├── Ubuntu-Lab.vmss
├── Ubuntu-Lab.vmsd
├── Ubuntu-Lab.vmsn
├── vmware.log
├── vmware-0.log
└── vmware-1.log

In this example, the .vmx file and the virtual disk components are core files. The firmware, memory, suspend, and snapshot files are state-dependent or optional. The log files are diagnostic records and are not part of the guest operating system's own logs.

VMware virtual machine file extensions

The VMX configuration file

The .vmx file is the main VMware virtual machine configuration file. It records how VMware should construct the VM's virtual hardware and connect its components.

Typical categories include:

• Guest operating system identification.
• Allocated virtual memory.
• Number of virtual CPUs and processor-related options.
• Virtual disk controllers and the disks attached to them.
• Network adapter type and connection mode.
• Display settings and virtual graphics hardware.
• CD/DVD, USB, sound, serial, and other virtual devices.
• VM power, firmware, and compatibility-related options.

A VMX file is text-based, so a text editor can usually display it. A powered-off VM might contain representative entries such as:

memsize = "4096"
numvcpus = "2"
guestOS = "ubuntu-64"
ethernet0.connectionType = "nat"
scsi0:0.fileName = "Ubuntu-Lab.vmdk"

These examples illustrate categories rather than a universal template. Exact parameter names and supported values vary by VMware version and virtual hardware configuration. Use VMware's graphical settings interface for normal changes.

The NVRAM virtual firmware file

The .nvram file is persistent virtual firmware storage. It preserves BIOS- or UEFI-related state and settings for the VM, such as firmware configuration and boot-related choices.

This is different from both the guest operating system and the VMX file. The guest operating system contains the system installed on the virtual disk. The VMX describes virtual hardware and connections. NVRAM preserves state maintained by the VM's virtual firmware.

Deleting or replacing an NVRAM file may reset firmware-related settings. In some cases that can change boot behavior, especially when the VM depends on UEFI settings, boot entries, or other firmware state. Treat it as a stateful binary file, not as a disposable configuration file.

VMDK virtual disk files

A .vmdk is part of VMware's virtual disk format. It represents a virtual hard drive containing the guest operating system, applications, user files, partitions, and filesystem data.

A virtual disk may be stored as one file, or as a small text-readable virtual disk descriptor plus one or more larger data-bearing extent files. For example:

Ubuntu-Lab.vmdk        small descriptor
Ubuntu-Lab-flat.vmdk   large disk extent

The descriptor describes disk properties, geometry, and the extent or extents that contain the data. The descriptor alone is not the complete disk. A disk can also be split into multiple extents, and snapshot-managed disks can introduce additional related components.

All files referenced by a virtual disk must remain together and retain the expected names and paths. If an extent is missing, renamed, inaccessible, or copied without its descriptor, VMware may be unable to start the VM or may report that the disk cannot be found.

Disk growth, compacting, and attachment

Growing a virtual disk changes the storage available to the guest, but the guest partition and filesystem may also need to be expanded before the extra capacity can be used. Compacting attempts to reduce host storage used by a disk, often after unused guest blocks have been prepared appropriately. Neither operation should be treated as a simple file rename or manual edit.

An existing virtual disk can be attached to another VM through VMware's virtual hardware settings. The disk's descriptor and every referenced extent must be available, and the attachment must match the intended controller and guest operating system. When recovering data, do not create a blank replacement disk in place of a missing original.

VMEM memory-related files

A .vmem file is a host-side file associated with the VM's allocated or active memory. It can be large because its size is related to the VM's memory configuration and current state. Its presence and size can vary with VMware version, VM power state, memory management, and configuration.

VMEM is not the same thing as a suspend-state file or a snapshot-state file. It represents memory-related data used by VMware, whereas .vmss represents saved execution state for suspension and .vmsn represents state associated with a snapshot.

Do not manually remove a VMEM file while the VM is running, suspended, or otherwise active. VMware may be reading or writing it, and removing it can damage the current VM state.

VMware log files

vmware.log and name-based or rotated .log files are VMware-generated diagnostic records. They can record power operations, virtual-device initialization, network problems, disk messages, graphics errors, permission failures, and startup failures.

VMware commonly rotates older logs so that a newer log is used while earlier logs remain under related names. After a failure, inspect the newest log first, then search its final entries for errors or references to missing files. Logs are not the same as guest operating system logs: VMware logs describe the host-side virtual machine process, while guest logs are created inside the guest.

Snapshot metadata and state files

A snapshot is a restore-point mechanism that can involve virtual disk changes and, depending on how it is created, saved runtime memory. Snapshot information is represented separately from the base VM configuration and base disk.

• .vmsd stores snapshot metadata, including information about snapshot relationships.
• .vmsn stores state associated with a snapshot, particularly when memory state is captured.
• Snapshot disk changes may also create or reference additional virtual disk components. These are part of a chain, not independent disposable files.

Snapshot capability depends on the VMware product edition and version. VMware Workstation Pro supports snapshots, while Workstation Player functionality may be limited or absent. A VM may also have been created or managed previously in an environment with snapshot support.

The VMSS suspended-state file

.vmss is saved state associated with suspending a VM. Suspend saves enough of the current execution session for VMware to resume it later. This differs from a normal guest shutdown, which asks the guest operating system to close applications and power down normally.

A suspended VM can resume with applications and session state still present. A shut-down VM starts through its normal firmware and guest operating system boot process.

VMSS is also different from VMSN. VMSS belongs to the suspend/resume mechanism; VMSN belongs to snapshot state. If saved-state data is deleted or cannot be read, the suspended session may be lost and the VM may need to start normally instead. Unsaved work that existed only in that session may not be recoverable.

File relationships during the VM lifecycle

The VMX and virtual disk files are the usual core components. Logs, memory files, suspend data, and snapshot files may be transient or state-dependent, but their presence can be essential for the current VM state.

Safe copying, backup, and migration

1. Shut down the guest operating system completely. Do not choose suspend if the goal is a clean backup.
2. Wait until VMware finishes its power-off operation.
3. Close VMware Workstation Player if appropriate, particularly before manually handling files.
4. Copy the entire VM directory, preserving its directory structure, file names, permissions where relevant, and all subcomponents.
5. Store the copy on backup storage with enough free space for every virtual disk and state file.
6. Open the copied VM by selecting its .vmx file in VMware.
7. Confirm that the configuration points to disks in the copied directory and that the guest starts correctly.
8. If VMware asks whether the VM was moved or copied, choose the response that matches what you actually did. This choice affects identity-related behavior such as generated virtual hardware identifiers and network identity.

Copying only the VMX file copies configuration, not the guest operating system or user data. Copying only one apparent VMDK can also be incomplete when the disk uses a descriptor plus extents or depends on snapshot-related disk files.

Which files matter for common tasks

Safe text-editing boundaries

Some VM files may be human-readable. The VMX file is generally text-based, and some VMDK descriptor files contain readable disk-description information. Read-only inspection can help you understand settings or identify referenced paths.

Do not open binary or stateful files in a text editor for modification. This includes virtual disk data extents, NVRAM, VMEM, VMSS, and VMSN files. VMSD metadata may contain readable text, but readability does not make it safe to edit.

For any manual VMX change:

• Make a verified backup first.
• Power off the VM and ensure VMware is not actively writing the file.
• Change one specific setting at a time.
• Record the original value and the reason for the change.
• Keep the change reversible and test the VM afterward.
• Restore the backup if VMware rejects the configuration or a device behaves unexpectedly.

Practical inspection examples

Inspecting a typical folder

For Ubuntu-Lab, classify the files as follows:

• Core: Ubuntu-Lab.vmx and all VMDK components.
• Firmware state: Ubuntu-Lab.nvram.
• State-dependent: Ubuntu-Lab.vmem and Ubuntu-Lab.vmss, depending on activity or suspension.
• Diagnostic: vmware.log and older rotated logs.
• Snapshot-related: Ubuntu-Lab.vmsd and Ubuntu-Lab.vmsn, when supported and used.

Understanding multiple VMDK files

If a small Ubuntu-Lab.vmdk refers to a large Ubuntu-Lab-flat.vmdk, the small file is a descriptor and the large file is a data extent. Copying the descriptor without the extent produces a configuration that names a disk but lacks the guest's actual data.

Reviewing configuration without changing it

With the VM powered off, open the VMX file in a text editor only to inspect categories such as memory, virtual CPUs, guest OS identification, network connection mode, and disk attachment. Close it without saving. Make routine adjustments through VMware's settings interface.

Distinguishing suspend and snapshot artifacts

A VM suspended from a running session may have a VMSS file. A snapshot-managed VM may have VMSD metadata, VMSN state, and additional disk-chain components. Suspend is intended to resume one saved execution session; a snapshot is a restore-point mechanism with its own disk and optional memory-state relationships.

Troubleshooting common file problems

A virtual disk cannot be found

If VMware reports that a disk is missing or inaccessible, inspect the newest vmware.log. Look for final error entries involving a missing path, permission failure, or unavailable file. Compare the VMX disk references with the actual directory contents, and confirm that every VMDK descriptor and extent is present.

Check whether the VM folder or an individual disk component was renamed or moved. Restore missing files from a complete backup or correct the reference through supported VMware configuration methods. Do not create a blank replacement disk when the original guest data is needed.

A copied VM has no expected guest data

If the copied VM configuration opens but the guest operating system or files are missing, compare the source and destination directories. A common cause is copying only a small VMDK descriptor while omitting its large extent files or snapshot-dependent disks. Re-copy the entire powered-off VM directory.

A suspended VM will not resume

Determine whether files were moved, renamed, or cleaned up while the VM was suspended. Review VMware logs for saved-state errors and check whether the VMSS and related files are available. If the suspended state cannot be recovered, use an appropriate VMware recovery path to discard only the saved state and boot normally. This can lose unsaved work from the suspended session.

Manual VMX editing causes errors

Compare the edited VMX file with the known-good backup. Check for malformed entries, unsupported values, duplicate settings, and incorrect file paths. With the VM powered off, restore the backup or reverse the specific change.

Snapshot files exist but snapshot functions are unavailable

Confirm the installed VMware product edition and version. Player functionality may not provide the snapshot management available in Workstation Pro, even if a VM folder contains artifacts from a prior snapshot-capable environment. Do not delete those artifacts manually; use a supported VMware edition and workflow when snapshot management is required.

Key exam and administration notes

• A VM is a host-side directory, not merely a VMX file.
• The VMX file defines virtual hardware and connections; it does not contain the guest's operating system data.
• VMDK files contain the virtual hard-drive data, and one virtual disk can require a descriptor plus multiple extents.
• NVRAM stores virtual firmware state, not guest filesystem data.
• VMEM, VMSS, and VMSN represent different kinds of memory or runtime state.
• VMSD is snapshot metadata; snapshot support depends on VMware edition and version.
• The newest VMware log is usually the first host-side diagnostic file to inspect after a startup failure.
• For a reliable backup or migration, shut down the guest and copy the complete VM directory.
• Never manually delete or edit stateful disk, firmware, memory, suspend, or snapshot files.

For related study, see Virtual Machine Files Overview.