Vmware Files Description

I always had lot of doubts on the different files used in VMware vSphere and I also have wasted alot of
my time on looking out for some website or blog where I can get a proper description of all the files used in VMware Vsphere.
Well finally I was successful to collect almost all the required and important details and would like to share here for all other users looking for the same.
 

nvram file

  • This file contains the CMOS/BIOS for the VM.
  • The BIOS is based off the PhoenixBIOS 4.0 Release 6 and is one of the most successful and widely used BIOS and is compliant with all the major standards, including USB, PCI, ACPI, 1394, WfM and PC2001.
  • If the NVRAM file is deleted or missing it will automatically be re-created when the VM is powered on.
  • Any changes made to the BIOS via the Setup program (F2 at boot) will be saved in this file.
  • This file is usually less then 10K in size and is not in a text format (binary).

 

vmdk files

These are the disk files that are created for each virtual hard drive in your VM. There are 3 different types of files that use the vmdk extension, they are:

*–flat.vmdk file

  • This is the actual raw disk file that is created for each virtual hard drive.
  • Almost all of a .vmdk file's content is the virtual machine's data, with a small portion allotted to virtual machine overhead.
  • This file will be roughly the same size as your virtual hard drive.

 

*.vmdk file

  • This isn't the file containing the raw data anymore.
  • Instead it is the disk descriptor file which describes the size and geometry of the virtual disk file.
  • This file is in text format and contains the name of the –flat.vmdk file for which it is associated with and also the hard drive adapter type, drive sectors, heads and cylinders, etc.
  • One of these files will exist for each virtual hard drive that is assigned to your virtual machine.
  • You can tell which –flat.vmdk file it is associated with by opening the file and looking at the Extent Description field.

 

*–delta.vmdk file

  • This is the differential file created when you take a snapshot of a VM (also known as REDO log).
  • When you snapshot a VM it stops writing to the base vmdk and starts writing changes to the snapshot delta file.
  • The snapshot delta will initially be small and then start growing as changes are made to the base vmdk file,
  • The delta file is a bitmap of the changes to the base vmdk thus is can never grow larger than the base vmdk.
  • A delta file will be created for each snapshot that you create for a VM.
  • These files are automatically deleted when the snapshot is deleted or reverted in snapshot manager.

 

*.vmx file

  • This file is the primary configuration file for a virtual machine.
  • When you create a new virtual machine and configure the hardware settings for it that information is stored in this file.
  • This file is in text format and contains entries for the hard disk, network adapters, memory, CPU, ports, power options, etc.
  • You can either edit these files directly if you know what to add or use the Vmware GUI (Edit Settings on the VM) which will automatically update the file.

 

*.vswp file

  • This is the VM swap file (earlier ESX versions had a per host swap file) and is created to allow for memory overcommitment on a ESX server.
  • The file is created when a VM is powered on and deleted when it is powered off.
  • By default when you create a VM the memory reservation is set to zero, meaning no memory is reserved for the VM and it can potentially be 100% overcommitted.
  • As a result of this a vswp file is created equal to the amount of memory that the VM is assigned minus the memory reservation that is configured for the VM.
  • So a VM that is configured with 2GB of memory will create a 2GB vswp file when it is powered on, if you set a memory reservation for 1GB, then it will only create a 1GB vswp file.
  • If you specify a 2GB reservation then it creates a 0 byte file that it does not use.
  • When you do specify a memory reservation then physical RAM from the host will be reserved for the VM and not usable by any other VM’s on that host.
  • A VM will not use it vswp file as long as physical RAM is available on the host.
  • Once all physical RAM is used on the host by all its VM’s and it becomes overcommitted then VM’s start to use their vswp files instead of physical memory.
  • Since the vswp file is a disk file it will effect the performance of the VM when this happens.
  • If you specify a reservation and the host does not have enough physical RAM when the VM is powered on then the VM will not start.

 

*.vmss file

  • This file is created when a VM is put into Suspend (pause) mode and is used to save the suspend state.
  • It is basically a copy of the VM’s RAM and will be a few megabytes larger than the maximum RAM memory allocated to the VM.
  • If you delete this file while the VM is in a suspend state
  • It will start the VM from a normal boot up instead of starting the vm from the state it was when it was suspended.
  • This file is not automatically deleted when the VM is brought out of Suspend mode.
  • Like the Vswp file this file will only be deleted when the VM is powered off (not rebooted).
  • If a Vmss file exists from a previous suspend and the VM is suspended again then the previous file is re-used for the subsequent suspensions.
  • Also note that if a vswp file is present it is deleted when a VM is suspended and then re-created when the VM is powered on again.
  • The reason for this is that the VM is essentially powered off in the suspend state, it’s RAM contents are just preserved in the vmss file so it can be quickly powered back on.

 

*.log file

  • This is the file that keeps a log of the virtual machine activity and is useful in troubleshooting virtual machine problems.
  • Every time a VM is powered off and then back on a new log file is created.
  • The current log file for the VM is always vmware.log.
  • The older log files are incremented with a -# in the filename and up to 6 of them will be retained. (ie. vmware-4.log)
  • The older .log files are always deleteable at will, the latest .log file can be deleted when the VM is powered off.
  • As the log files do not take much disk space, most administrators let them be

 

*.vmxf file

  • This is a supplemental configuration file in text format for virtual machines that are in a team.
  • Note that the .vmxf file remains if a virtual machine is removed from the team.
  • Teaming virtual machines is a Vmware Workstation feature and includes the ability to designate multiple virtual machines as a team, which administrators can then power on and off, suspend and resume as a single object — making it particularly useful for testing client-server environments.
  • This file still exists with ESX server virtual machines but only for compatibility purposes with Workstation.

 

*.vmsd file

  • This file is used to store metadata and information about snapshots.
  • This file is in text format and will contain information such as the snapshot display name, uid, disk file name, etc.
  • It is initially a 0 byte file until you create your first snapshot of a VM and from that point it will populate the file and continue to update it whenever new snapshots are taken.
  • This file does not cleanup completely after snapshots are taken.
  • Once you delete a snapshot it will still leave the fields in the file for each snapshot and just increment the uid and set the name to “Consolidate Helper” presumably to be used with Consolidated Backups

 

*.vmsn file

  • This is the snapshot state file, which stores the exact running state of a virtual machine at the time you take that snapshot.
  • This file will either be small or large depending on if you select to preserve the VM’s memory as part of the snapshot.
  • If you do choose to preserve the VM’s memory then this file will be a view megabytes larger then the maximum RAM memory allocated to the VM.
  • This file is similar to the vmss (Suspend) file.
  • A vmsn file will be created for each snapshot taken on the VM, these files are automatically deleted when the snapshot is removed.