The ESXi host scratch partition change to shared storage was not persistent after a reboot.

Products

• VMware vSphere ESXi
• VMware vSphere ESXi 7.0

Issue/Introduction

Change the ESXi scratch partition to share storage that followed the Creating a persistent scratch location for ESXi 8.x/7.x/6.x ,  the ScratchConfig.ConfiguredScratchLocation came back to default location after reboot ESXi host . 

When ESXi try to active the new scratch partition during the boot up , the share storage VMFS has not mounted yet as the storage is a slow discovery device .

YYYY-MM-DDTHH:MM:SS nativeExecutor[2098623]: SetupLegacyScratch: /vmfs/volumes/#######-#########-####-############/.locker-example-host: scratch path not active
YYYY-MM-DDTHH:MM:SS nativeExecutor[2098640]: Configured scratch location (/vmfs/volumes/#######-#########-####-############/.locker-example-host) is not available. Please verify that the path is accessible.

........

YYYY-MM-DDTHH:MM:SS cpu76:2099912)LVM: 17386: File system '[Example-Datastore, #######-#########-####-############]' (LV #######-#########-####-############) mounted in 'rw' mode. 

The new scratch location in share storage is not available during boot up , as the shared storage was not mounted yet . 

YYYY-MM-DDTHH:MM:SS cpu39:2098241)qedf:(2b:0.2):qedfc_link_update_handler:1846:Info: ST(LINK): LINK_UNKNOWN->LINK_UP
YYYY-MM-DDTHH:MM:SS cpu34:2098269)qedf:(2b:0.3):qedfc_link_update_handler:1846:Info: ST(LINK): LINK_UNKNOWN->LINK_UP
.........
YYYY-MM-DDTHH:MM:SS cpu24:2097842)ScsiClaimrule: 3470: Enabling claimrules for MP plugins.

Environment

VMware vSphere ESXi 7.0.0 U3 

Resolution

Start adjusting from devListStability of 10, increasing by 30 seconds at a time  , finally the devListStabilityCount=80 fixed the issue . How to change the devListStabilityCount , please refer to Slow storage device discovery causes bootbank/scratch to not get mounted