A vSphere virtual machine (aka VM) is made up of a variety of files. In fact, many of those files carry over to Workstation and Fusion. But there are certain files that are specific to vSphere and may have slightly different behaviour than other platforms. Generally speaking, however, most behave the same and most can be edited. But remember that just because you can doesn’t mean you should.
So let’s take a look at what each of the files are and what they are used for. We’ll start with one of the more important files: vmx.
<virtual-machine-name>.vmx (and associated .vmx~ and .vmx.lck files)
This is the virtual machine (VM) configuration file. It describes all the things that make up the virtual hardware (the generic virtual hardware shell). The .vmx file itself is the main configuration file. This file contains the listing of all the various devices we find in the “four food groups” (CPU, Memory, Network, Disk) along with all the “side food groups” (e.g., parallel ports, com ports, PCI devices, USB, etc. ) It’s a simple text file and you can look at it via commandline or download a copy of a vmx file of a VM and look at it in your favourite text editor. DO NOT upload vmx files that you editor with Wordpad, Word or the like as extra characters may be added. All changes should be done through the “Edit Settings” option on a VM through the vSphere traditional client or vSphere Web Client.
There is no definitive list of additional options to add to a vmx file, although it’s been attempted to be created in the past (http://sanbarrow.com/vmx.html — keep in mind this isn’t sanctioned or supported by VMware Support).
Some changes can help VM behaviours. For example, sometimes we can see repeated characters when using a Linux or Windows system. KB196 details how to address this. You can edit the VM or vmx file and add the following line:
keyboard.typematicMinDelay = "2000000"
This option gives more “pause” between each key stroke and that should stop the repeated character effect.
Now another vmx file that appears when a VM is powered on is the . lck file. In addition to the vmx .lck there may be additional hidden .lck files; you can see these at the command line by typing
The vmx .lck file is created to indicate a lock on the VM by the ESXi host (usually in the form of running worlds/processes in the ESXi vmkernel). This helps identify that the VM “belongs” to a specific ESXi host and is active. You can get state info by using the following commandline (ESXi commandline) to see what VMs exist, get state info and power on/off VMs (amongst other options):
Now what is interesting is what happens between VMFS datastores and NFS datastores. Take a look at the following screenshots of two VMs I have in my home lab, one on a VMFS datastore and one on an NFS datastore.
Did you see it? Look closely and you’ll see an extra file on VMFS. It’s the vmx~ (that “squiggly” line is known as a tilde). The definition of a tilde, besides its use in Spanish, is “a symbol similar to a tilde used in mathematics to indicate similarity, and in logic to indicate negation.” It seems apropos that the tilde is used as this indicates a file similar to the one with the tilde. Specifically, a backup of the vmx file.
The idea here is that the tilde vmx file is a backup, read-only version of the vmx file and if something goes wrong with the original, this can be used to replace the original. When a VM is power cycled (not an OS reboot but either a VM shutdown or reset), the changes get merged permanently into the file. But remember that this “extra” protection only applies to VMFS (hence, another reason to use VMFS over NFS). What’s interesting is that when you do a change to a VM, that change is actually recorded to both the .vmx and the .vmx~ files. When you use a command like diff, you can see what lines have changed between the two. And yet, both files have the changes. But the one won’t keep the changes until the virtual hardware is rebooted or shutdown.
Now, I didn’t go into all the innards of the vmx file. The reason is that you really shouldn’t have to either and the few times where it becomes necessary, it will be at the advice of VMware support or for a specific scenario (such as the one above). I’ll probably continue to randomly post more on the various files over the next few weeks or so along with some View related stuff (my favourite topic).