Understanding VMware virtual machine files can help ease management tasks and simplify infrastructure cleanup.
Once you know VMs from a hardware perspective, you can study the components that make up a VM on an ESX/ESXi host. You can find various VMware VM file types in the VM's directory on the host. The three main types are NVRAM files, VMX files and VMDK files.
VMware virtual machine files are organized in Virtual Machine File System (VMFS). If you look at the list of files associated with the VM -- use an secure copy protocol (SCP)-based tool or follow VMware's recommendations -- you'll notice that most files start with the actual name of the VM, followed by different file extensions denoting file type. You might not see all possible file types in VMFS until your VM reaches a certain state. For example, you only see a VSWP file when you power on the VM. Likewise, you only find a VMSS file when you suspend your VM. You can use WinSCP to view your VM directory listing.
What are VMware virtual machine files made of?
The NVRAM file. This small file contains the BIOS (basic input/output system) that the VM uses to boot. It's similar to a physical server that has a BIOS chip that lets you set hardware configuration options. A VM also has a virtual BIOS contained in the NVRAM file. You can access the BIOS when a VM first starts up by pressing the F2 key. Whatever changes you make to the hardware configuration of the VM are then saved in the NVRAM file. This file is in binary format, and if deleted, the VM automatically recreates it when you power it back on.
The VMX file. This file contains all the configuration information and hardware settings of the VM. Whenever you edit the settings of a VM, this file stores all of that information in text format. This file contains a wide variety of information about the VM, including its specific hardware configuration -- i.e., RAM size, network interface card info, hard drive info and serial/parallel port info -- advanced power and resource settings, VMware tools options and power management options. Although you can edit this file directly to make changes to a VM's configuration, don't do so unless you're sure you know what you're doing. If you make changes directly to this file, make a backup copy first.
VMDK files. All virtual disks are made up of two files: a large data file equal to the size of the virtual disk and a small text disk descriptor file, which describes the size and geometry of the virtual disk. The descriptor file also contains a pointer to the large data file, as well as information on the virtual disk's drive sectors, heads, cylinders and disk adapter type. In most cases, these files have the same name as the data file associated with it -- i.e., myvm_1.vmdk and myvm_1-flat.vmdk. You can match the descriptor file to the data file by checking the Extent Description field in this file to see which flat, RDM (raw device mapping) or delta file is linked to it.
Other types of VMDK files
The different types of VMDK files that you can use with VMware VMs include the following:
The flat.vmdk file. The system creates this default large virtual disk data file when you add a virtual hard drive that isn't an RDM file to your VM. When using thick disks, this file is approximately the same size as what you specify when you create your virtual hard drive. Each virtual hard drive that a VM has configured should have one of these files.
The delta.vmdk file. You only use these VMDK files when making snapshots. When you create a snapshot, it halts all writes to the original flat.vmdk file, and the file becomes read-only; the system writes changes to the virtual disk to these delta files instead. The initial size of these files is 16 MB, and they grow as needed in 16 MB increments as you make changes to the VM's virtual hard disk. Because these files are a bitmap of the changes made to a virtual disk, a single delta.vmdk file can't exceed the size of the original flat.vmdk file. The system creates a delta file for each snapshot that you create for a VM. Their file names increment numerically -- i.e., myvm-000001-delta.vmdk, myvm-000002-delta.vmdk, etc. When you delete the snapshot, the system automatically deletes these files after you merge them back into the original flat.vmdk file.
The rdm.vmdk file. This is the mapping file for the RDM format that manages mapping data for the RDM device. The mapping file presents to the ESX host as an ordinary disk file, available for the usual file system operations. However, to the VM, the storage virtualization layer presents the mapped device as a virtual SCSI device. The metadata in the mapping file includes the location of the mapped device -- i.e., name resolution -- and the locking state of the mapped device. If you do a directory listing, you'll see that these files appear to take up the same amount of disk space on the VMFS volume as the actual size of the logical unit number that it's mapped to, but in reality, they are a small size. The system creates one of these files for each RDM you create on a VM.
The VSWP file. When you power on a VM, the system creates a memory swap file. You can use this in lieu of physical host memory if an ESX host exhausts all of its physical memory because of overcommitment. The system creates these files equal in size to the amount of memory assigned to a VM, minus any memory reservations (default is 0) that a VM might have set on it -- i.e., a 4 GB VM with a 1 GB reservation has a 3 GB VSWP file. A VM always has these files but only uses them if a host exhausts all of its physical memory. As VM memory read/written to disk is slower than physical host RAM, your VM performance degrades if it uses this file. These files can take up quite a large amount of disk space on your VMFS volumes, so ensure that you have adequate space available for them, as a VM won't power on if it doesn't have enough room to create this file. The system deletes these files when you power off or suspend a VM.
VMs lock the VSWP, flat.vmdk, delta.vmdk, VMX and LOG files during runtime.
The VMSS file. This file preserves the memory contents of the VM so it can start up again where it left off when you suspend a VM. This file takes up approximately the same space as the amount of RAM assigned to a VM, including empty memory contents. When you bring a VM out of a suspended state, the system writes the contents of this file back to the physical memory of a host server. However, the file doesn't automatically delete until you power off a VM -- an OS reboot won't work. If a previous suspend file exists when you suspend a VM again, the system reuses this file instead of deleting and recreating it. If you delete this file while the VM is suspended, then the VM starts normally and not from a suspended state.
The VMSD file. The system uses this file to store metadata and other information about each active snapshot on a VM. This text file starts at 0 bytes in size until you create a snapshot. A VMSD file updates with information every time you create or delete snapshots. Only one of these files exists, regardless of the number of snapshots running, as they all update this single file. The snapshot information in a VMSD file consists of the name of the VMDK file and VMSD file each snapshot uses, the display name, and description and the unique identifier (UID) of the snapshot. Once you delete all your snapshots, this file retains old snapshot information but increments the snapshot UID to use with new snapshots. It also renames the first snapshot to Consolidate Helper, presumably to use with consolidated backups.
The VMSN file. The system uses this file to store the state of a VM when you take a snapshot. The system creates a separate VMSN file for every snapshot on a VM and automatically deletes it when you delete the snapshot. The size of this file varies based on whether you choose to include the VM's memory state with your snapshot. If you choose to store the memory state, this file is slightly larger than the amount of RAM assigned to the VM, as the system copies the entire memory contents, including empty memory, to this file. If you choose not to store the memory state of the snapshot, this file is fairly small -- under 32 KB. This file is similar to the VMSS you use when you suspend VMs.
The LOG file. The system creates this file to log information about the VM, and it's often used for troubleshooting purposes. A VM's directory has a number of these files. The current LOG file is always named vmware.log. The system retains up to six older LOG files with a number at the end of their names -- i.e., vmware-2.log. The system creates a new LOG file either when you power a VM off and back on or when the LOG file reaches the maximum defined size limit. The number of LOG files the system retains and the maximum size limits are both defined as VM advanced configuration parameters: log.rotateSize and log.keepOld.
The VMXF file. This file is a supplemental configuration file retained for compatibility with VMware Workstation. It's in text format, and Workstation uses it for VM teaming where it can assign multiple VMs to a team so you can power them on or off or suspend and resume them as a single object.
The CTK file. VMware CTK files list any changes made to the VM between backups. This file describes the VMDK block and grows in proportion with the number of VMDK blocks. There is one CTK file per VMDK. Change tracking files originated with VMware's Changed Block Tracking technology for incremental backups. The CTK file stores information about what VM information blocks changed, avoiding unnecessary block backups. VMware snapshots also use CTK files. Like LOG and NVRAM files, CTK files are small.
Other less-frequent VMware virtual machine files include the VMEM VM paging file and the VMTM configuration file for team data. Like VMSN files, VMEM files back up a VM's memory. They exist when you run the VM or in the event of a VM crash. The VMEM files support VM teams, a feature in VMware Workstation that enables a group of VMs to work together via a private LAN segment.
Check out the VMs on your own VMware hosts to see the various files that make up these VMs. You might find old data on VMFS volumes. Before you delete any files, make sure that you no longer need the files you delete and that the VM isn't using them.
Editor's note: This article was originally published in August 2009. It was updated and republished in March 2019.
Create and populate a vSphere content library and create VMs from templates
Use snapshots to manage virtual servers
Virtualize server storage with storage tiering and disk allocation