Virtual Machine Files in VMware Player

Learn what VMware Player VMX, NVRAM, VMDK, log, VMEM, VMSD, VMSN, and VMSS files store and how to handle them safely.

A VMware Player virtual machine (VM) is a software-defined computer. It is represented by several files stored together in a folder on the host operating system, which is the physical computer's operating system. The guest operating system, such as Ubuntu or Windows, runs inside the VM.

The VM folder is the unit users commonly copy, move, back up, or inspect. File names usually begin with the VM name, although some files use fixed names such as vmware.log. A typical folder might contain files such as Ubuntu.vmx, Ubuntu.nvram, Ubuntu.vmdk, and vmware.log.

How VMware Player VM files fit together

The files have different responsibilities. The VMX configuration file tells VMware Player how to assemble the virtual hardware. The VMDK virtual disk contains the guest operating system, applications, and guest data. The NVRAM file preserves virtual firmware settings. Logs record activity for investigation, while snapshot and suspend files preserve special VM states.

A VMX file must remain associated with every virtual disk that it references. Snapshot-related files and saved-state files should also be treated as parts of the same VM collection rather than as unrelated files that can be selected individually.

Where VMware Player stores virtual machine files

When you create a VM, VMware Player stores its files in a folder on the host. The exact folder depends on the location selected during VM creation or later management. To inspect the files, locate the VM's folder using the host operating system's file manager.

Do not assume that the VM's display name is the only identifier. Most files use the VM name as a prefix, but logs and additional disk files may follow different naming patterns. A VM can also use multiple VMDK-related files because of its disk layout or enabled features.

VMware Player virtual machine file types

File extension or naming pattern	Typical example	Purpose	When it commonly appears	Handling importance
`.vmx`	`Ubuntu.vmx`	Primary VM configuration: memory, processors, networking, storage references, and other VMware settings.	Normally present for every VM.	Essential. It is the configuration entry point and must stay consistent with referenced disks.
`.nvram`	`Ubuntu.nvram`	Virtual BIOS or firmware data, including firmware-level settings.	Typically present for a VM that has initialized its virtual firmware.	Normally retain it with the VM, especially when preserving firmware settings.
`.log` or `vmware.log`	`vmware.log`	Records VM activity and events, including configuration, device, startup, and runtime information.	Commonly created or rotated as the VM is used.	Useful for diagnosis, but it does not contain the guest operating system's disk contents.
`.vmem`	`Ubuntu.vmem`	Virtual machine paging or memory-related data associated with the VM's memory state.	May be created or used while the VM is active.	Do not confuse it with a suspend file or a snapshot-state file. Handle it as part of the VM while the VM is active.
`.vmdk`	`Ubuntu.vmdk`	Virtual disk containing the guest operating system, applications, and guest data.	Normally present for a VM with a virtual hard disk.	Essential. A VM may have multiple VMDK-related files, all of which may be required.
`.vmsd`	`Ubuntu.vmsd`	Snapshot data and metadata describing the snapshot arrangement.	Appears when snapshots are used.	Keep it with the associated snapshot and VM files. It is not the complete saved disk or memory state by itself.
`.vmsn`	`Ubuntu.vmsn`	Running VM state captured when a snapshot is taken.	May appear when snapshots capture the VM's running state.	Part of snapshot handling; do not delete or separate it arbitrarily.
`.vmss`	`Ubuntu.vmss`	State of a suspended VM, allowing it to resume from the suspended condition.	Appears when the VM is suspended.	Keep it with the VM until the suspended state is resumed or intentionally discarded.

The VMX configuration file

The file matching <VM name>.vmx is the primary VMware virtual machine configuration file. It records the VM's virtual hardware and configuration choices, including allocated memory, processor settings, networking, virtual storage-device references, and other VMware options.

When you open a VM in VMware Player, Player uses the VMX file to determine how to configure and start that virtual computer. The VMX file does not normally contain the guest operating system's files. Instead, it points to the virtual disks and describes how those disks are connected to virtual hardware.

If a VMX file is separated from its referenced VMDK files, VMware Player may report that a disk or device is missing. Renaming a VMDK without updating the configuration can produce the same type of failure.

The NVRAM firmware file

The file matching <VM name>.nvram contains virtual BIOS or firmware data. It preserves firmware-level settings for the VM, similar to how a physical computer preserves certain firmware settings independently of its operating system disk.

NVRAM is not the guest disk and does not replace the VMX file. It is another part of the VM's configuration state that should normally remain in the VM folder.

VMware log files

VMware log files record VM activity and events. A common name is vmware.log; some environments or VMware file sets may also contain a log using the VM name, such as Ubuntu.log. Logs can provide evidence about startup failures, virtual devices, configuration problems, and runtime events.

For a startup problem, first locate the log in the VM directory and inspect entries related to the time of failure. Logs are diagnostic records, not core VM storage: they do not contain the guest operating system, applications, or guest data stored in the VMDK.

Virtual disk files: VMDK

A file matching <VM name>.vmdk is a VMware virtual disk file. From the guest operating system's perspective, it represents a virtual hard disk. Its contents can include the guest operating system, installed applications, user files, and other guest data.

A VM may use more than one VMDK-related file. For example, a disk layout or a VMware feature can divide disk information across multiple files. Therefore, the file with the simplest name is not necessarily the only disk file required by the VM.

Snapshot files: VMSD and VMSN

A snapshot is a saved restore point managed by the virtualization software. It allows a VM to be associated with an earlier point in its disk and, where applicable, running state.

The <VM name>.vmsd file contains snapshot data and metadata. It describes snapshot information, but it is not the complete saved disk or memory state by itself.

The <VM name>.vmsn file stores the running state of a VM at the time a snapshot is taken when that state is captured. It is associated with the snapshot feature and should be kept with the related VM disks, configuration, and snapshot metadata.

A snapshot is different from simply powering off a VM. A powered-off VM has no running execution state to resume. A snapshot is also different from manually suspending a VM: snapshots create restore points managed as part of snapshot history, whereas suspension saves the current execution state for later continuation.

Suspend state files: VMSS

Suspending a VM pauses its execution and saves enough state for the VM to continue later. The file matching <VM name>.vmss stores the state of a suspended virtual machine.

A VMSS file is therefore a saved continuation state, not a normal powered-off condition. It is also not the same as a VMSN snapshot-state file. A suspended VM is intended to resume from its current paused condition; a snapshot is a restorable point associated with snapshot management.

Which files appear in different VM states?

VM condition	Core files	Optional or state-related files	What the files represent
Powered off without snapshots	Usually VMX, NVRAM, one or more VMDK-related files, and logs.	VMEM, VMSD, VMSN, and VMSS may be absent.	Configuration, firmware, virtual disk contents, and historical activity records.
Running	VMX, NVRAM, VMDK-related files, and current logs.	VMEM may be created or used for memory-related data.	The VM is executing, and additional memory-related files may reflect active operation.
Suspended	VMX, NVRAM, VMDK-related files, and logs.	VMSS commonly represents the suspended execution state; VMEM may also be associated with memory handling.	The VM can resume from its saved suspended condition.
Using snapshots	VMX, NVRAM, VMDK-related files, and logs.	VMSD and possibly VMSN files, along with snapshot-related disk files.	Snapshot metadata, disk state, and possibly captured running state are connected to the VM.

This table describes common patterns, not a guarantee that every installation has exactly the same file list. Files can vary according to VM activity, disk layout, VMware version, and enabled features.

Example: identifying an Ubuntu VM folder

Suppose the VM is named Ubuntu. A representative folder might include:

Ubuntu.vmx — the settings and virtual hardware configuration.
Ubuntu.nvram — the VM's virtual BIOS or firmware data.
Ubuntu.vmdk — the virtual disk containing Ubuntu, its applications, and guest data.
vmware.log — a record of VMware Player activity and events.
Ubuntu.vmsd and Ubuntu.vmsn — files that may appear after snapshots are created.
Ubuntu.vmss — a file that may appear after the VM is suspended.

The example may also contain additional VMDK-related files. Treat the folder as one related collection rather than assuming that these example names are the complete list.

Safe handling when copying or moving a VM

Identify the complete VM folder on the host operating system.
Power off the VM before copying or relocating files when you need a consistent offline copy. Do not rely on a file copy made while the VM is actively changing its disk or state.
Include the VMX configuration, NVRAM firmware data, all required VMDK-related files, and any snapshot or suspended-state files that belong to the VM.
Keep the files together in the intended VM collection. A configuration file without its referenced disks is not a usable complete VM.
After the copy or move, open the VM through its configuration entry point and check for missing disks or devices before deleting the original.

Troubleshooting file-related problems

The VM cannot be opened

Check that the VMX file exists and that its referenced VMDK files are present in the intended VM collection. A missing or separated VMX is a configuration-entry problem; a missing or renamed VMDK is a virtual-disk dependency problem. Avoid arbitrary renaming or deletion because file names and references are related.

A copied VM has incomplete snapshot history

Verify that the copy included the VMSD snapshot metadata, any VMSN snapshot-state files, associated snapshot disk files, and the VMX and base disk files. Snapshot history depends on the associated configuration and disk state; copying only one snapshot file is not sufficient.

A suspended VM does not resume

Check whether the VMSS suspended-state file is present and whether the VM was copied while it was suspended. A suspended VM is not equivalent to a cleanly powered-off VM. Use the log files to gather diagnostic context before changing any VM files.

The VM fails during startup or device initialization

Locate vmware.log or the relevant VM log in the VM directory. Log entries can help identify virtual hardware, configuration, and startup issues. Also confirm that required VMX, VMDK, and related files have not been moved, deleted, or renamed.

Key points to remember

The VM folder is the practical unit for inspection, copying, moving, and backup.
VMX is the primary configuration file; VMDK contains the guest disk contents.
NVRAM preserves virtual firmware settings.
Logs help diagnose problems but do not contain the guest operating system's disk contents.
VMEM is memory-related, VMSD stores snapshot metadata, VMSN stores snapshot running state, and VMSS stores suspended state.
Optional state files appear according to whether the VM is running, suspended, or using snapshots.
Power off the VM before making a consistent file-level copy, and do not edit or delete files solely because of their extensions.

For foundational context, review what a virtual machine is, what a guest operating system is, and VMware Player log files.