Deep Intro to VMware ESX, Part 1

More and more of us are using VMware ESX to do our job. We are virtualizing servers, use these for our testing and we build virtual machines for packaging purposes. And it is very easy.

In these series of articles I will guide you through ESX.

When we build a virtual machine, these machines consists out of several files.

I use Vmware ESX a lot for maintaining and running my virtual machines that I use to package software with wise packaging studio and of course Symantec Workspace Virtualization.

The files that are together a VM (virtual machine)

Generally about 4 files make a VM: xxx.vmdk, xxx.vmx, vmware*.log, and nvram. There could be more than one .vmdk file associated to a VM (virtual machine). All files, but the .vmdk file(s) are always in the same (sub)directory. It is most convenient to name that subdirectory xxx.

The older .log files are always deleteable at will. The latest .log file can be deleted when the VM is powered off. A new log file will be created during the next VM power-on. As the log files do not take much disk space, most administrators let them be. If for some reason the current log file vmware.log starts growing too rapidly, you can rename+compress it, or even delete it. It is recommended to execute logrotate daily to check for the logs. More on this later.

The nvram file contains CMOS/BIOS settings for the VM. If the file does not exist, it will be (re)created next time the VM powers up. If any changes were made to the nvram via VM's BIOS setup, do not forget to remake those changes. The most common change to the BIOS settings of a VM is to change the boot device order. The default is floppy, hard drive, CD/DVD. You might want to raise the CD/DVD to higher in the list to be able to boot from there.

In addition to the .vmdk file, a .vmdk.REDO file will exist in the same directory, if non-persistent, undoable, or append disk mode is active for that particular virtual SCSI disk. The .vmdk.REDO file can grow up to several gigabytes. How large it will grow, depends only on what file/disk operations are done on the disk.

When the Virtual machine is started there will also be a VSWP file existing. This file has the same size as the amount of virtual memory you are addressing to the machine. So if you give your virtual machine 1 GB of memory the VSWP file will be 1024MB in size.

If you have a lot of virtual machines on your storage area network, it can also be a good idea to place a txt file in the same directory where your virtual machine is. In this txt file you can place information about the virtual machine, especially the owner of that machine, will be very helpful.

An alternative to the per VM .txt file approach is a single .txt file which contains information on all the VMs on the server. Okay, you can maintain this document anywhere with any tools, but remember, pure text files are most easily accessed and maintained on the ESX Server by the administrator(s).

Naming a VM, and its files is important. It will be crucial once there are dozens or even hundreds of VMs. It is a recommended practice to:

• Have a short, but descriptive name for the VM without any spaces. Usually this is VM's hostname/computername.
• Have the VM's name to show up consistently in the configuration file directory name (or VMFS partition name).
• Have the VM's name to show up consistently in all the filenames related to the VM.
• Have the VM's name to show up consistently in the one line VM description in the .vmx file.
• Have a brief descriptive .txt file next to the .vmx file to document the VM.

A powered on VM can be suspended, much like a laptop or any of the later Windows. VMware uses the term "Suspend to disk". "Hibernate to disk" might be a more accurate term here. When entering the suspend (hibernate) state, a suspend file will be created. It has a filename extension .vmss. It is very practical to direct the suspend file to the same directory where the VM's operating system .vmdk file is.

If you have two or more VMware ESX Servers, you might want to try suspending a VM on one ESX Server, and resuming it on another. Practical in many cases...

The .vmss (the suspend file) file will be a few megabytes larger than the maximum RAM memory allocated to the VM.

Example list of files associated with virtual machine 'temp'

This is a realistic example list of files.

• /vmconf/temp/temp.vmx

The configuration file defining all aspects of the VM.

• /vmconf/temp/nvram

BIOS/CMOS settings of this VM. This file is (re)created if it is missing.

• /vmconf/temp/vmware.log /vmconf/temp/vmware-0.log /vmconf/temp/vmware-1.log

Server created log file(s). Can be deleted to save disk space.

• /vmconf/temp/temp.txt

Small text file documenting this VM. It is strongly recommended to create this file.

• /vmfs/public01/temp-sys.vmdk

Boot(/application) disk (first physical disk) of the VM. It could have more than one partition. Windows VMs usually have only one partition, but Linux/BSD/Netware/Solaris VMs have more than one.

• /vmfs/public01/temp-data.vmdk

Data disk (second physical disk) of the VM. It could have more than one partition. Partitioning depends on the requirements of the VM.

Planning and documenting

Planning is important with ESX. It is especially important with the storage allocated to VMs. Some preliminary questions to answer are:

• How many VMs will be installed on the ESX Server?
• Are they file/print/database/application servers, or what? This is important because database servers will have different performance settings then file servers
• How many virtual memory will these machines need?
• What kind of storage allocation will be needed?
• How much storage is initially reserved to a every VM?
• What are the CPU requirements per VM?
• What are the network I/O requirements per VM?
• What are the disk I/O requirements per VM?
• What are the memory requirements per VM?
• How much storage is required for suspended VMs?
• Will non-persistent, undoable or append disk mode be used?

Documenting is another extremely important issue with ESX Server, as these systems easily become extremely complex. With VMware ESX it is so easy to just build, deploy or even clone machines and finally you will get stuck with various machines, not knowing anymore what they are intended to do.

It is best practice to maintain a txt file on the VMware server or use Microsoft Excell to keep track on your machines.

In the next part we take a deep inside look for your storage.

When you have that done correctly, it will make your life much easier.