Deploying ESXi hypervisor hosts into the data center can be achieved in a number of different ways, which gives us a number of deployment scenarios to consider, depending on the hardware choice made. The first key decision is whether to opt for a traditional stateful installation of the ESXi hypervisor or to go stateless. The second pivotal decision to make is the destination media, where the hypervisor binaries will be installed, assuming that they are not being stored only in memory as part of a stateless implementation.

These options are discussed in later sections of this document. This section describes the structure and layout of the ESXi hypervisor so that an informed choice for the planning of host deployment can be made, and to determine how that decision will affect other virtual infrastructure components.

The way the hypervisor is deployed and the hardware it detects during deployment determines which partitions are created, and where items, such as logs and dump files, are stored. There is no way to manually define the partition layout during the ESXi installation procedure.

When ESXi is installed on to local hard disks (typically configured as a RAID 1 mirror), all possible partitions are created as shown in the following figure.

 

However, during an installation to either removal media (such as SD or a USB device) or a remote installation such as a SAN LUN (in a boot from SAN scenario), several of these partitions are absent post-installation.

For instance, the physical location where logs are written depends on the installation device used during the ESXi deployment. When the ESXi installation device is an SD card, USB key, or a remote boot LUN from an SAN device, a local scratch partition is not created on the installation media automatically during the deployment. Despite its size, ESXi 6.x always sees this type of installation as remote, and as such, logs are stored in RAM disk (a disk drive that is made up of a block of volatile memory) and therefore lost when the host is rebooted.

The reason for this is that USB/SD devices are sensitive to high I/O volumes, so the installer will not place the scratch partition on this type of device. During installation, the ESXi installer first scans for a local
4-GB VFAT partition. If it is unable to find one, it will then scan for a local VMware vSphere VMFS volume to use to create a scratch directory. If no local VFAT partition or VMFS volume is found, the last resort is to put the scratch partition in /tmp/scratch (a scratch location on the local RAM disk).

 

After this type of installation, you will see a warning on your ESXi hosts in vCenter Server indicating that their log files are stored on non-persistent storage (see the VMware Knowledge Base article Syslog not configured messages on ESXi host console or in logs (1032460) at http://kb.vmware.com/kb/1032460). Where this is the case, scratch space can be manually configured on the ESXi host using the VMware vSphere Client™, VMware vSphere Web Client, VMware vSphere PowerCLI™, or as part of a scripted installation procedure.

Because log messages that are stored on RAM disk are not retained after a reboot, troubleshooting information contained within the logs and core files is lost. In addition, if a persistent scratch location on the host is not configured properly, you might experience intermittent issues due to lack of space for temporary files, and the log files will not be updated. This can be problematic in low-memory hosts, but is not a critical issue for ESXi operation.

If the installation device is considered local during deployment, as illustrated previously, the ESXi host is not typically required to be manually configured with a scratch partition. The ESXi installer automatically creates a 4-GB Fat16 partition on the target device during the installation process, if there is sufficient space to do so. If persistent scratch space is configured, most of the logs are located on the scratch volume, and the /var/log/ directory contains symlinks (symbolic links—a type of file that contains a reference to another file in the form of an absolute or relative path) to the persistent storage location.