Welcome to VxBlock support video series. This is in regards a potential VMFS-L locker partition
corruption on SD cards on ESXi 7.0. The issue is detailed in DellCI knowledge article 00083376.
Symptoms are when an ESXi host boots off of a USB SD card the there are logs or boot-up errors that
indicate the boot drive is corrupt. The problem may cause a purple diagnostic screen error. If
related to this problem the diagnostic message should indicate or imply a boot disk failure.
Further details are in DellCI CB 0083376 and the related VMware KB is listed here.
To verify if this is your issue what you're looking for in the vmkwarning.log file are
any errors in regards to the bootbank. In the vm kernel observation event log file
you're looking for errors in regards disc corruption or the locker error,
and in the vmkernel.log file you're looking for corruption errors in regards the sd device.
So change directory to /var/log/ and from here you can list the log files, the 'ls-ltr' lists them
in reverse order, from the most recently updated. To search the log files themselves use the cat vm
log file name and pipe it to a grep for a string. The string you're looking for in
this case, in the vmkwarning.log file, we're looking for the string 'boot'.
In the observation and events log file we're looking for the string 'damaged' and in the
vmk warning vm kernel.log file we're looking for the string 'corrup'.
This issue is resolved in vSphere 7.0 Update 2c release.
The fix enhances the USB host controller driver to tolerate command timeout failures
to allow ESXi sufficient time to release the USB device resources.
As a best practice it is recommended not to set the dump partition on USB storage devices,
and there is a workaround. If you are unable to move directly to ESXi 7.0 update 2c to reduce
heavy access to the sd cards by setting the RAM disk to enable or create it if it doesn't exist.
Using PuTTY, SSH into the host and log in as user 'root'.
Once logged in you can use the esxcli command line to verify if the tools disk has been created
or not. If it has been created then it will actually list the contents as
we have here because it's already been created. If not you will see an error.
If created we need to verify what it's set to. The current setting is 'Int
Value' and you can see that colon is zero, so it's currently set to the default setting at zero.
We need to set it to one to resolve our issue here for the current workaround.
If the RAM disk parameter had not been created then you would have to create
it before continuing. The command created is given here, in our case when we try and create
it it tells us it's already there because we've just seen it. And then we need to set,
because it's already there we need to set the RAM disk parameter to 1, which is not the default.
So just to check that we have set it correctly we use the list command, and here we can see the int
value is one now. In this case a reboot is required before it will take effect,
and we can also, just another thing we can check before we reboot, is you can just check and
see if the /tools directory has been created here. And as we can see it hasn't so then we
need to reboot the host and check it again when it comes up. On boot-up
ESXi will check the value of tools RAM disk, and copy the files to the /tools RAM disk.
You can run the command 'esxcli system visorfs ramdisk list' and this command shows the RAM
disks that have been created, in particular the /tools RAM disk appears in this output
and it has a used value of 200 megabits, so the tools have been copied there successfully.
If you'd like, also you can just list the 'ToolsRamdisk' setting using the command we
used before, and you can see that it's currently set to one. If you really would like to you can
cd to the /tools directory and just verify that it is populated and you're good to go.