Not something you will be dealing with during normal day-to-day vSphere operations, but you can bump into problems if you don’t have a scratch partition.
This happened to me while upgrading some ESXi host with VMware Update Manager, but can also happen when you are trying to generate log files for VMware Support. And what’s more annoying then having system log generation problems when trying to deal with another error in your vSphere environment.
What is the ESXi scratch partition?
The scratch partion is a 4 GB VFAT partition that is created on a target device that has sufficient space available and is considered “Local” by ESXi.
The scratch partition is used for a couple of things:
* Store vm-support output (if scratch partition is unavailable the output will be stored in memory)
* During first boot the partition will be configured through syslog for retaining logfiles
* Userworld swapfile (when enabled)
The scratch partition is created and configured during ESXi installation or the autoconfiguration phase when the ESXi server first boots.
ESXi selects one of these scratch locations during startup in order of preference:
- 1. The location configured in the
/etc/vmware/locker.confconfiguration file, set by theScratchConfig.ConfiguredScratchLocationconfiguration option - 2. A Fat16 filesystem of at least 4 GB on the Local Boot device.
- 3. A Fat16 filesystem of at least 4 GB on a Local device.
- 4. A VMFS Datastore on a Local device, in a
.locker/directory. - 5. A ramdisk at
/tmp/scratch/
There are two examples where scratch space may not be automatically defined on persistent storage. In each case, the temporary scratch location will be configured on a ramdisk.
- 1. ESXi deployed on a Flash or SD device, including a USB key. Scratch partitions are not created on Flash or SD storage devices even if connected during install, due to the potentially limited read/write cycles available.
- 2. ESXi deployed in a Boot from SAN configuration or to a SAS device. A Boot from SAN or SAS LUN is considered Remote, and could potentially be shared among multiple ESXi hosts. Remote devices are not used for scratch to avoid collisions between multiple ESXi hosts.
So for the record, a scratch partition isn’t always created, and even isn’t required to run ESXi, but it can result in strange problems during vSphere operations. So better be safe, then sorry and create your scratch partition in advance.
Always have a scratch partition
The reason for this article is the fact that I ran into trouble while updating my ESXi host with VMware Update Manager. This was due to the fact that my servers had SAS disks and no scratch partition was configured. This led to this VMware KB article which explained how to configure your scratch partition by setting the advanced option ScratchConfig.ConfiguredScratchLocation.
This solved my problem and I’ve made it a best practice to configure my scratch partition, by setting ScratchConfig.ConfiguredScratchLocation, in my kickstart script. The scratch partition is to be located on the local VMFS datastore of my server. After all ESXi creates this local VMFS datastore from the disk space that isn’t used (when dealing with servers with local disks). This remaining disk space is more then enough to host the scratch partition. This way the scratch partition persistent and is always created, even in the case of local SAS disks.
For more information, and the sources of all my information for this article, have look at the following links:
About the Scratch Partition – page 56 – ESXi Installable and vCenter Server Setup Guide
VMware KB article 1033696 : Creating a persistent scratch location for ESXi
VMware KB article 1014953 : Identifying disks when working with VMware ESX
VMware ESXi Chronicles : Ops changes part 5 – Scratch Partition
Was just looking at this after reading your blog as I was interested to see why it would not create a scratch partition on SAS disk. Reading the ESXi installable and vCentre setup guide though I realise it auto creates the scratch partion if using ESXi installable. It creates a random unique volume name which does seem to persist across a reboot.
Is the issue only with ESXi embedded?
yes. embedded only.
esxi5.1 seems to regard SATA as remote, not SAS, so this might be an improvement now.
seems like i’ll just create a scratch LUN on the SAN and assign it to the hosts. Only q is if to have one per host, or a large one to be shared.
h