When trying to update a number of hosts in the ESXi cluster of a customer I first ran into the issue that scanning the host for updates would result in the following error: “Could not scan esx12 for patches”. Searching through the VMware KB I learned that this is probably due to a corrupted scratch partition on the ESXi host, see: KB1020283. This scratch location is, amongst other things, used to store the staged updates for the ESXi host.
Diving into the ESXi host I noticed there was no scratch partition at all. This is strange in my case, since I was sure that after re-installing the hosts a few months ago, my colleague had set the scratch location of all ESXi hosts manually. When double checking this myself I noticed that the scratch location was empty. See: host – configuration tab – advanced settings – ScratchConfig. After kicking my colleague I set the scratch location manually and to double check if it was set correctly I noticed the setting was empty again. While setting the correct location I only got a “Completed successfully” message so it was very strange the setting was empty again.
Since I couldn’t find anything in the VMware KB about not being able to set this value, I tried setting the value through a PowerShell command, but that wouldn’t stick either. My last resort was a reboot which normally feels a bit like being defeated. Nonetheless, after the reboot, the scratch location was still empty, but changing the value worked and sticked. Another reboot is then needed to activate this new scratch location. After this reboot I was able to rescan the host for patches and remediate the host.
Well, this of course solved only half of the problem, because this left me with 8 hosts in this cluster to change the setting. Think you know what happened next, indeed: “PowerShell to the rescue”
VMware KB 1033696 “Creating a persistent scratch location for ESXi” has a good explanation of how to set the scratch location, including the powershell script to do it. The most important commands:
Setting the scratch location:
Get-VMHost -Name esx12 | Set-VMHostAdvancedConfiguration -Name "ScratchConfig.ConfiguredScratchLocation" -Value "/vmfs/volumes/ESX_VMFS00_SCRATCH/esx12/"
Viewing current scratch location setting:
Get-VMHost -Name * | Get-VMHostAdvancedConfiguration -Name "ScratchConfig.ConfiguredScratchLocation"
Viewing current scratch location used:
Get-VMHost -Name * | Get-VMHostAdvancedConfiguration -Name "ScratchConfig.CurrentScratchLocation"
Watch these last two carefully, one is the scratch location that is configured, the other is the location currently in use! If these are not equal the host is probably still waiting for a reboot. The first command only sets the location for one host at a time.
the only time I had to set this up was with ESXi 3.5 for HA configuration and I believe with ESXi 4.x, this requirement no longer applies. I haven’t came across any article suggesting creating scratch location as a standard build process.
I also had this problem and found a hotfix from vmware to fix it (then my scratch stayed in GUI config) then i was able to apply all updates
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1037190
Vishy – it depends what your requirements are. Do you want to keep a local copy of your ESXi logs that persist through a reboot? If so, then I would say you should add it to the standard build process. Now in many cases, as long as you have local drives this is done for you, but there are several examples where this is not the case. For example, some UCS hardware treats the local drive as remote and does not configure the scratch space.