My configured scratch location for some reason doesn't work after upgrading to ESXi 6.5.
I set up parameter ScratchConfig.ConfiguredScratchLocation to a persistent storage. The folder exists and worked before the upgrade.
After each reboot ScratchConfig.CurrentScratchLocation is always set to /scratch while ScratchConfig.ConfiguredScratchLocation is /vmfs/volumes/volume01/scratches/host01
I'm not sure if this is related but to upgrade ESXi I had to provide boot parameter preferVmklinux=TRUE as my USB drive wasn't visible and later I run these commands:
esxcli system settings kernel set -s preferVmklinux -v FALSE
esxcli system module set --enabled=false –m vmkusb
Thanks for your help in advance,
Install the newest elxiscsi driver works for me
See my post in German forum
Das oben gepostete DELL Dokument (bzw. das was dazu drin steht) brachte mich auf folgende Idee:
Server (ohne lokale HD) mit Lenovo Customized Image 6.5 U1 GA installiert und den Scratchpfad auf einen
Datastore umgelegt. Die Einstellung ist wie hier schon beschrieben, wirkungslos. Selber Effekt mit dem Ignorieren
von "ScratchConfig.ConfiguredScratchLocation". Das Lenovoimage enthält den elxiscsi in der Version 11.2.1152.
Lösung => "Schau mal ob's was Neueres gibt" => JA
VMware ESXi 6.5 elxiscsi 11.4.1184.0 iSCSI driver for Emulex and OEM Branded Adapters
das findet man im VMware Download bei den Treiber und Tools => Driver-CDs.
[root@<my_host>:~] esxcli software vib update -d /vmfs/volumes/<my_datastore>/esxi-patches/VMW-ESXi-6.5.0-elxiscsi-11.4.1184.0-offline_bundle-6410288.zip
Message: The update completed successfully, but the system needs to be rebooted for the changes to be effective.
Reboot Required: true
VIBs Installed: ELX_bootbank_elx-esx-libelxima.so_11.4.1184.0-03, EMU_bootbank_elxiscsi_11.4.1184.0-1OEM.6188.8.131.5298673
VIBs Removed: ELX_bootbank_elx-esx-libelxima.so_11.2.1152.0-03, EMU_bootbank_elxiscsi_11.2.1152.0-1OEM.6184.108.40.20640417
Dann Reboot - danach funktioniert die Einstellung für den Scratch Pfad wie gewünscht.
Did you ever manage to resolve this?
I have the same issue.
That is rather unusual. The thing about ScratchConfig.ConfiguredScratchLocation is that vSphere will error out if your targeted location is not correctly named.
With that said, as I have done too many upgrades to recall all of them. Clear out all files in the folder on the datastore and then update ScratchConfig.ConfiguredScratchLocation. Reboot, it should work. I have never seen it not work and I'm running several hosts on vSphere 6.5.
I had the same issues und until now no solution. I tried the LUN caption for the folder and ID, but both didn't work, even if I clear the whole folder after every try. After each try the folders "downloads", "log" and "va"r were but are empty.
I'm seeing the same with ESXi 6u3 HP Customised from July 2017. /downloads, /log and /var are created on the NFS server when ESX boots, but ESX still sets its current scratch location to /scratch
Currently out of ideas.
I have excat the same Problem on two DL380G7, HPE Custom Image 6.0u3 Juli 17 and local Datastore
can confirm the issue with build 5572656 (ESXi 6.0 Patch 5). After the update ScratchConfig.CurrentScratchLocation is reset to "/scratch" and will not change no matter how often I change the "ScratchConfig.ConfiguredScratchLocation" value. Also made multiple reboots but the change still does not take effect.
after rolling back the host to 5224934 (ESXi 6.0 Express Patch 7a) its back to normal. ScratchConfig.CurrentScratchLocation is set to "/tmp/scratch" and can be change to whatever you want.
another thing I noticed - the issue is only solved by a rollback of the host. if you just force-downgrade the issue will persist.
I've upgraded to ESXi, 6.5.0 Update 1 (build 5969303) and the issue still persists.
I checked all methods described here Creating a persistent scratch location for ESXi 4.x/5.x/6.x (1033696) | VMware KB and there is no way to set up custom scratch location.
We are experiencing the exact same issue after adding and rebooting 2 6.5 Servers with the Dell customized image to a new vCenter Appliance.
Maybe the below information is helpful!?
--> "Scratch partition stops working after hardware or software iSCSI is enabled on ESXi with the elxiscsi Emulex driver".
Thanks André, that was the solution for our problem!
On HPE Custom images the affected vibs are the following:
Removing them clears the warning on HPE Servers with 6.0U3. On 6.5 the vibs are the same mentioned in the Dell document.
Thanks for this..
Removing the following vibs on an HPE custom ESXi 6.5 image on BL460c Gen8 and 9's worked for me as well:
Not worked for me on a ProLiant BL460c Gen9, only removing: Emulex_bootbank_ima-be2iscsi_220.127.116.11-1OEM.518.104.22.1681820, the vib scsi-be2iscsi not exist.
I'm Running VMware ESXi, 6.5.0, 5969303 (HPE Custom Image).
Has this host been upgraded from version 5.5?
Please provide a complete list of installed vibs, i.e. the output of esxcli software vib list
It's resolved now, I delete also the vib: EMU_bootbank_elxiscsi_11.2.1238.0-1OEM.622.214.171.12498673.
Thanks a lot.
How do I know if the driver is needed or not? I'm using Software iSCSI on a HPE FlexFabric Adapter. vSphere shows me, that the driver "elxnet" is used on this NIC.
How can I find out if VIB "elxiscsi" and "elx-esx-libelxima" is used by some other device? Is it save to remove the library "elx-esx-libelxima" when "elxnet" is in use?
just in case i might help someone else:
had this problem with updating to hpe custom build for esxi 6.5 U1 on DL 380 Gen 8.
The solution provided by vmware was to set the "name" of the local attached storage (not /vmfs/...) into Syslog.global.logDir into the brackets.
in my case it than looked like
So this could be solved without uninstalling vib's.
Thanks to the kind VMWare-lady, giving me a callback in less than 1 hour and solving the problem!
Make sure location has confingured with format [Datastorename]/foldername ex .. [datastore1] /systemlogs
System logs are stored on non-persistent storage (2032823) | VMware KB