This page is designed to aid in designing, setting up, and operating the VMware ESX Server platform. Most of this information has been gathered both during working with the product on different production environments, and during the several training sessions delivered on the product. This information is current as of version 1.5.2 of VMware ESX Server.

As this information has been gathered mostly for Trivore's VMware ESX Server class students, the
representation might not always be the best possible. Also, some information is pretty purely GNU/Linux
oriented. This is intentional, as many technical people are still pretty new to the GNU/Linux stuff running on
the Console OS.

These hints and tips do not replace neither the excellent VMware ESX Server manual, nor a decent hands on GNU/Linux knowledge, nor a decent, hands-on-oriented VMware ESX Server classroom education. Any Unix knowledge makes your life a lot easier.

This document is frozen as of now for v1.5.x series. For later information, please look for the documents for later ESX Server versions. If there is something you might want to see here, or you would otherwise send me feedback, please email us. The maintainer of this information is Kari Mattsson of Trivore Corp.

Generally about 4 files make a VM: "xxx.dsk", "xxx.cfg", "xxx*.log", and "nvram". There could be more than
one .dsk file associated to a VM (virtual machine). All files, but the .dsk file(s) are always in the same
(sub)directory.

The nvram file might occasionally corrupt for some reason. If that happens, power off the VM and just delete
the file. It will be recreated 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.

In addition to the .dsk file, a .dsk.REDO file will exist in the same directory, if non-persistent, undoable, or append disk mode is active for that virtual SCSI disk. The .dsk.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.

It is a good idea to place a brief descriptive "xxx.txt" file next to the "xxx.cfg" file to document what this VM is, what is its business purpose, what is the OS version and level, what are the main installed applications, and who is/are responsible for the VM. If you absolutely do not want the .txt file, you could place that same information to the .cfg's comment lines. Is the information safe there, is untested.

Have the VM's name to show up consistently in all the filenames related to the VM. Example:
/data/vm001/vm001.cfg, /data/vm001/vm001.txt, /vmfs/private1/vm001-os.dsk, /vmfs/private1/vm001-
data.dsk

Have the VM's name to show up consistently in the one line VM description in the .cfg file. VM
description is usually managed via the Edit Configuration menu option in the web management user
interface (MUI).

A powered on VM can be suspended, much like a laptop. During suspending, a suspend file will be created. It has a filename extension .vmss, and by default it is created to the .cfg file directory. It might be a better idea to direct it to the same directory where the VM's operating system .dsk file is.

Planning is important with ESX. It is especially important with the storage allocated to VMs. Some preliminary
questions to answer are: What are the VMs to be installed on ESX Server? What operating systems will be
installed? Are they file/print/database/application servers, or what? What kind of storage allocation will be
needed? How much storage is initially reserved to a each VM? Are VMs executed on more than one ESX
Server at the same time? 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. Mainframe and Unix style management attitude is required. Document everything carefully. It will
save your day often. The few line .txt file next to .cfg file is especially nice. An example skeleton .txt file
follows:

Name of the VM (virtual machine): [vm###]
Last update of this file........: [dd-Mmm-yyyy / updater's name]
Business purpose of the VM......: [short description]
Responsible person(s) for the VM: [name, contact (email and/or telephone)]
OS name and version in the VM...: [OS name, update level]
Installed core application(s)...: [app1, app2]

Maximum number of partitions (which can contain data) per SCSI disk (=logical drive on RAID systems) in
Linux kernel 2.4.x based systems is 14. The Console OS is based on kernel version 2.4.9. Of these max 15
partitions 3 are primary (1-3), 1 is extended (4), and 11 are logical (5-15). Extended partitions never contain any
actual data. It merely acts as a container for the logical partitions.

If you are using CD/DVD ISO images, or floppy images, create a partition for them to the Console OS. Images are very handy for OS and application installations. They are much more reliable and convenient than the actual CDs. Example commands on how to create these images are given later in this document.

On IBM servers, the 50 MB System Partition accessible with [Alt-F1] is partition /dev/sda4. VMware ESX
Server recognises this partition as "Old VMware Core Dump Partition". Usually you do not want to touch this
partiton, so leave it alone. Non-IBM systems might also have this kind of service partition.

shared - On fibre channel or similar SAN, make this partition visible to multiple ESX Servers at the
same time. This setting is recommended for clustered VMs which need to share virtual SCSI disks (.dsk
files).