It's recommended by VMware to have a persistent scratch location for VMkernel logs in case that ESXi is installed on USB stick or SD card (1Gb is minimum size). ESXi scratch partition, for those particular cases, resides in memory – in RAM disk, which is limited in size. The size is only 512 Mb, which is taken out of the server's available memory. Having scratch location in RAM might get problematic when running lots of VMs so the memory gets restrained.
Also, if you reboot the host, you'll basically loose the VMkernel logs so having persistent scratch partition is a good thing. You would certainly want to keep the logs, don't you? You can then use Splunk to present and seek the logs with through GUI, or use Syslog bundled with vCenter.
Which problems you can run into if you don't configure persistent storage for the log files? You might experience HA agent issues on those miss-configured hosts, or you're not able to activate HA at all. Other symptoms might show “general system Error” in vSphere Update manager (if you're using it). You'll basically need to create a persistent scratch location for ESXi. It's straightforward process, which can be done through vSphere Client, PowerCLI or vCLI. Let's see the vSphere client way.
How to configure scratch location for ESXi logs? Follow those steps
- Connect to vCenter Server or the ESXi host using the vSphere Client > Select your host > Sonfiguration > Storage
- Right click datastore (local or shared) and select Browse
- Create folder for this ESXi host named for example “scratch”> close the datastore browser.
- Select the host > configuration > Advanced (software section) > ScratchConfig > Change the ScratchConfig.ConfiguredScratchLocation
For example:
/vmfs/volumes/DatastoreName/ESXi5-01/scratch
- Click OK > go and put the host in maintenance mode and reboot for the configuration to take effect.
Now, if you have for example 3 hosts in your cluster, just create a separate folder for each of your host, so the hosts don't overwrite each other's data.
Some more read and sources:
- ESXi host is unable to generate support logs because local storage is full – https://kb.vmware.com/kb/1007329
- Exporting diagnostic data fails on ESXi embedded – https://kb.vmware.com/kb/1006582
- Patch installation and log collection on ESXi 4.1 Update 1 fails when /tmp/scratch is missing – https://kb.vmware.com/kb/1037190
- ESXi hosts without swap enabled cannot be added to a VMware High Availability Cluster
- Creating a persistent scratch location for ESXi 4.x and 5.x
- Check for ESXi scratch persistence (Forbes Guthrie's blog)
- Recommended disk or LUN sizes for VMware ESX/ESXi installations
- Storage requirements for ESXi Installations – VMware Pub
Bonsoir,
S’il vous plait,j’ai besoin d’aide!! j’arrive pas a installé l’hyperviseur ESXI 6.7.0 sur la vmware workstation 12 .Le message d’erreur est “logs are stored on non-persistent storage ”
j’ai cherché sur le Net et j’ai rien trouvé malheureusement.
aidez-moi s’il vous plaît !!
Merci
Hi Liza, first of all, this website is in English. It’s principally as respect to other users that I’ll reply to you in the langue of Shakespeare. You’ll probably need to update your VMware Workstation software. The latest few versions were able to install VMware ESXi hypervisor just fine.
If not you can use the free VMware Player for the same job (without some advanced functionalities).
Sadly, there is an issue with this that has existed since ESXi 6.0 – and continues today through the latest ESXi 6.7.0 build-13644319 – where a specified value for ScratchConfig.ConfiguredScratchLocation may (or may not) NOT persist across reboots, reverting to the default setting /tmp/scratch. This is documented in VMware KB 2151270 https://kb.vmware.com/s/article/2151270 . That document also provides a workaround that involves configuring the Syslog.global.logDir value instead. Although it is frustrating to find this setting reverts to default for unknown reasons – the more maddening aspect is that its disappearance is non-deterministic. What I mean by that is I can set the value on a given host and it is retained across the first three or four or 30 reboots, but magically on the 31st (or some other random number) reboot it decides to not persist. In a similar manner – I just configured this setting on six identical hosts (all were installed 6.5 using same media and post-install configurations applied via script – they are IDENTICAL except for hostname and IP addresses) that had just been upgraded to the latest ESXi 6.7.0 build-13644319 via installing a new profile from the offline installer and then rebooted. Only two of six hosts retained my ScratchConfig.ConfiguredScratchLocation value; four hosts reverted to default. I reset the value on the four that had failed first time around and rebooted them – 3 retained the setting after reboot and one did not. I have since reapplied this setting more than 20 times to this host and tried both rebooting and shutting down/powering on and NOTHING I do seems to make the setting persist across any reboot on this host. I’m at my wits end with this issue and it appears to have gotten ZERO development effort from VMware, as the KB article states it affects 6.0 and 6.5 which means it has been a problem for >2 years and still “Currently, there is no resolution.”. I requested VMware to add 6.7 to the list of affected versions as well.
I found a bad and ridiculous solution:
– install ESXi 6.5u3
– set “ScratchConfig.ConfiguredScratchLocation” option
– reboot
– update to ESXi 6.7
In my case it worked.
Soorry, it does not work… After one more reboot it setting reset to default.
It’s an old post and ESXi 5 is out of support since ages…
@Patrick Long
Thank you for commenting on this. I thought I was the only facing this issue. I didn’t realize it was as widespread as you described.
I’m running a home lab with ESXi installed on a USB stick. I thought it was due to me configuring a trail version of vCenter as an appliance and then removing it from the inventory. I guess, I’ll go down this route in trying to figure out how to get this to stop being a problem.
I have my server on a UPS, but without a fully-fledged backup generator at the ready, my server has gone down; or I have brought it down with the time allotted to me.
Wow, what a weird issue that VMware has yet to correct by now….
@Patrick Long: According to VMware KB 2151270 can be solved by installing an Emulex iSCSI driver version later than 11.2.x.