This is third post in as many days, regarding the ESXi scratch partition – here is the first and the second.

Aaron Delp posed the question – what should be a “best practice” regarding this?

Should we all run around making changes?  Personally, I think that at the very least you should go out and run a discovery of your environment.  It’s up to you to know what you are dealing with, and it certainly seems as though there are some inconsistencies out there.

What I am particularly interested in is what to do if you find hosts that aren’t set with a persistent scratch location, and there is a local disk available (as I described in the first post).  VMware state in their KB that if you want to create an addition to your kickstart script then you should do the following:
scratchdirectory=/vmfs/volumes/DatastoreName/.locker-$(hostname 2> /dev/null)-$(esxcfg-info -b 2> /dev/null)
mkdir -p $scratchdirectory
vim-cmd hostsvc/advopt/update ScratchConfig.ConfiguredScratchLocation string $scratchdirectory

There is no reason you can’t also use these lines to retro-fit this setting to existing servers.  But I’m not sure this is always the best approach.  The reason is that this assumes that all your hosts have no 4GB scratch partition created.  If the ESXi server already has 4GB set aside as FAT scratch partition, why would you want to move the scratch location to VMFS datastore?

I guess there are two schools of thought here:
1) Change all your hosts to use a VMFS datastore, regardless of the availability of any existing allocated space. That way you know all your servers are same.
2) Stick with the build default, whatever that is.  So if it created the partition – use it; if it already set a scratch location on the first VMFS volume it found – use that; or if it thought the local disks were remote THEN create a folder and set this as the scratch location.

Forcibly standardise or go with defaults – that is your choice.  Standardising is probably better in larger environments where managing unknowns is less attractive than loosing a little disk space.  In smaller places where it is important to eek out every bit of value from your CAPEX, then you might want to use the FAT partition if it’s already there.  Either way, you’ll also need to factor in the “cost” of making changes, as it requires a reboot which needs planning and execution.  If you want to standardise then go ahead and use something like the script above.

If you don’t want to move the scratch location if the 4GB FAT partition exists, then try something like this:
if df -h | grep -q 4.0G
then echo "Scratch partition already exists, let's use that"
else
if cat /etc/vmware/locker.conf | grep -q .locker
then echo "Persistent scratch location already set to VMFS folder"
else
then mkdir -p /vmfs/volumes/datastore1/.locker
vim-cmd hostsvc/advopt/update ScratchConfig.ConfiguredScratchLocation string /vmfs/volumes/datastore1/.locker
fi
fi

Now I don’t purport to be a scripter, so test my hack carefully – it may kill all your kittens by mistake.  And let me know if you have a better suggestion.