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

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

book

Article ID: 374917

calendar_today

Updated On: 06-24-2025

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
VMware vSphere ESXi 8.0.0 U3

Cause

This is due to delay in device being presented to the Storage.The jumpstart process is designed to continue as long as new paths or devices are being discovered. It will exit if no new device or path is detected within the last 3 seconds, which is controlled by the devListStabilityCount boot option.

Resolution

Implement a longer wait time for storage-path-claim to discover devices devListStabilityCount boot option can be modified. By default it is 3 seconds. This could be increased to may be 7 or 10 seconds so that the device with scratch gets discovered.

esxcli system settings kernel set -s devListStabilityCount -v 10

Reboot the ESXI to apply the changes.