Even though it’s not new, still came across wrong setup of scratch partition, which could cause boot media issues. If you had a statefully deployed ESXi host, it could boot from any sources like standard HDD or SSD or even Flash Drive (Pendrive) or SD Card. In case of HDD/SSD usage this setup is not that important, however it’s became very important when using SD Cards.
During the installation or after the first boot, a new 4GB standard sized partition called scratch partition is created by the installer, if there is enough space on the local disk. In case of absence of any local disk or they are present but not enough space on it, the scratch partition will be created in ramdisk, which could be a problem in low-memory situations. But let’s assume we have enough space on the SD card(s) we booted.
Scratch partition is used for storing temporary data, log files and diagnostic operations, and also used as storage of the ESXi syslog system. SD Cards are (and early ssd disks was) sensitive for continuous read/write cycles and logging is exactly doing that. Therefore if we have SD cards as boot media, this two settings (at least) must be targeted to another media like local disks or san/nas datastores.
Both parameters can be found on the UI in the advanced settings, just look for:
- ScratchConfig.ConfiguredScratchLocation
- Syslog.global.logDir
Or use PowerCLI to get the required info:
Get-VMHost | Get-AdvancedSetting -Name "ScratchConfig.ConfiguredScratchLocation" |ft -autosize
Get-VMHost | Get-AdvancedSetting -Name "Syslog.global.logDir" |ft -autosize
As a result you should see [] /scratch/log for logdir, and empty value means scratch location. This is what needs to be modified.
There are multiple ways to change the target of scratch partition. It can be done in the UI or PowerCLI for instance. First of all we need a datastore as a target. As I mention it can be done any physical disk (hdd, ssd) or a slice of a storage array. In every case we need to mount this datastore to the particular esxi (or multiple esxi hosts) and we have to know it’s unique name or it’s unique id (UUID).
To get the datastore name go to the ESXi host › Click on Datastores tab and select one of them.
I recommend to create a new datastore apart from other datastores running vm on those. In this case, create a new LUN on the array and associate with the required group of esxi hosts, then on the ESXI hosts, click on Actions › Storage › New Datastore. Follow the procedure and finish. Datastore should be named to be easily identified when needed, use talking names like : Datastore-Locker or LogStore
Another way is to use UUID of a storage which can be found if you navigate to Configure › Storage Devices › datastore name › Location under Datastore Details.
Probably you have the datastore name or UUID so far, so let’s add it where necessary. Navigate to the advanced settings and look for the same parameters, and enter the path of the storage.
Adding $hostname means path will be the hostname of the current ESXi host so this parameter value can be spread across all esxi hosts or its usable with host profiles. $datastore is the variable contains the name of the datastore assigned to store items of scratch partitions and logs.
- ScratchConfig.ConfiguredScratchLocation
Value: /vmfs/volume/NameOfYourDatastore/$hostname/scratch/
- Syslog.global.logDir
Value: /vmfs/volume/NameOfYourDatastore/$hostname/syslog/
Configuring the same with PowerCLI:
$datastore = Get-VMhost -Server $vc |get-Datastore | where {$_.Name like '*Locker' }
Get-VMHost | Get-AdvancedSetting -Name "ScratchConfig.ConfiguredScratchLocation" |Set-AdvancedSetting -Value "/vmfs/volume/$datastore/$hostname/scratch/"
Get-VMHost | Get-AdvancedSetting -Name "Syslog.global.logDir" |Set-AdvancedSetting -Value "[$datastore] /$hostname/syslog/"
As closing I’ve mentioned multiple SD Cards to boot. It is possible, at least in Cisco UCS environment to configure RAID-1 for the installed SD Cards. I’m sure other manufacturers also have some kind of RAID solutions for their hardware. This is providing a High Availability solution for the booting media. But in many cases this isn’t a life insurance as both of the cards could be bad, or there will be mismatch between the card parameters. But this could be different in every case.
Thanks for reading.