Hi,
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,
Lukasz
Just tested this myself with "try'n'error": Seems the two VIBs are not necessary. After removing elxisci and elx-esx-libelxima.so all my NICs (based on FlexFabric on elxnet) used for the SW iSCSI Initiator are still working fine. Also the NICs (same type) used for my VMNetworks are looking good.
This works for the log files to go to Syslog.global.logDir but the ScratchConfig is still points to /scratch. Had this issue with a Lenovo and well as Dell custom iso.
Removing the following VIB fixed it for me:
EMU_bootbank_elxiscsi_11.2.1238.0-1OEM.650.0.0.4598673.
I was experiencing this on a HP BL620 G7 with the HP ESXi 6.0 Update 3 July 2017 image.
I noticed a new Emulex driver was released a few days ago. I haven't been able to track down the release notes, but I tried it out anyways. The problem is now fixed in my environment.
I upgraded to be2iscsi 11.4.1178.0 and elxnet 11.4.1179.0. Not sure the elxnet upgrade was necessary, but I figured I should keep them in line with each other.
Hello Since this forum pointed to the right track of the problem.
I would also like to share my experience on the problem.
I have not just uninstalled a driver that is needed for hardware, but a solution that solves the problem.
After several installs of the ESX and testing with different iSCSI drivers I can announce you a final version.
After you install the current HPE Custom Image "VMware ESXi 6.5.0 Update1-5969303-HPE-650.U1.10.1.0.14-Jul2017"
uninstall the two iSCSI specific drivers.
(esxcli software vib remove --vibname = elxiscsi) and (esxcli software vib remove --vibname = elx-esx-libelxima.so)
Then reboot the Host and Install the older driver (VMW-ESX-6.5.0-elxiscsi-11.1.216.0-4403610) or via (Update Manager).
Thus, everything should work again including the CNA.
Lg: Heinz
Install the newest elxiscsi driver works for me
See my post in German forum
Hallo,
Das oben gepostete DELL Dokument (bzw. das was dazu drin steht) brachte mich auf folgende Idee:
Ausgangspunkt:
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
Installation Result
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.650.0.0.4598673
VIBs Removed: ELX_bootbank_elx-esx-libelxima.so_11.2.1152.0-03, EMU_bootbank_elxiscsi_11.2.1152.0-1OEM.650.0.0.4240417
VIBs Skipped:
Dann Reboot - danach funktioniert die Einstellung für den Scratch Pfad wie gewünscht.
Ralf
Hallo Ralf,
vielen Dank für deinen Tip, hat auch bei mir (HP DL380P Gen8) perfekt funktioniert und scheint mir als die bessere / sauberste Lösung!
mfg,
I'm running HP ProLiant BL460c Gen7 blades on the HP July 2017 custom ISO for ESXi 6.5 Update 1, and removing the elx-esx-libelxima.so vib worked for me! Thanks so much...this was really frustrating me!
I can confirm that updating Emulex vibs to version 11.4.1184.0 solved the problem on my IBM/Lenovo servers:
esxcli software vib update -d /vmfs/volumes/volume_temp/VMW-ESXi-6.5.0-elxiscsi-11.4.1184.0-offline_bundle-6410288.zip
I didn't need to remove anything.
FYI, from Dell:
VMware vSphere 6.5.x on Dell EMC PowerEdge Servers Release Notes
When specific versions of elxiscsi Emulex driver is installed or is part of ESXi, then enabling the hardware or software iSCSI stops the scratch partition to work. This prevents the redirection of logging to a persistent data store causing loss of log data across reboots.
Update der iscsi-Driver ist definitiv die beste Lösung! Auch ich habe mit dem update auf die neueste Version (VMware ESXi 6.5 elxiscsi 11.4.1210.0 iSCSI driver for Emulex and OEM Branded Adapters) das scratch-Problem endgültig lösen können mit HPE Custom Imge 6.5.
Die Alternative mit VIB-Remove funktioniert zwar auch erstmal, bringt aber bei der nächsten Prüfung mit dem Update-Manager wieder Probleme. Der installiert die VIBs wieder nach (wenn man die Baseline nicht anpasst) und alles geht von vorne los...
Danke nochmal an Ralf.
Seems I've got the same problem at two sites. At one site it worked by removing the elxiscsi and elx-esx-libelxima.so driver, but not on the other site. Neither did it work to install the newer driver, v11.4.xxx. I've also set a datastore and a new location for syslog files. Nothing works.
The site that doesn't work was installed three weeks ago with ESXi 6.0U3 latest Dell ISO and then VUM updates. Today it was upgraded via VUM with Dell A04 ISO for ESXi 6.5U1.
The hardware is Dell R630 with Intel NICs. Connected via Software iSCSI to EqualLogic SAN. New scratch folder located on SAN (/vmfs/volumes/Datastore/.locker/esxi01).
I'm stuck :smileyplain::smileyangry:
Seems Dell released a version A5 today (built two days ago):
ESXi 6.5 U1 Build Number: 6765664
Dell Version : A05
Dell Release Date : 12 Dec 2017
VMware Release Date: 05 Oct 2017
Downloading as we speak
Ok, so I did a clean install with the new 65U1 Dell A05 ISO and now all worked fine. I was able to redirect scratch, and no need to uninstall drivers
That's good to hear.
Are you able to tell us the driver versions that come with it?
e.g.
# esxcli software vib list | grep iscsi
ima-be2iscsi 10.5.101.0-1OEM.600.0.0.2159203 EMU VMwareCertified 2017-04-20
scsi-be2iscsi 10.5.101.0-1OEM.600.0.0.2159203 EMU VMwareCertified 2017-04-20
Thanks!
THANK YOU THANK YOU THANK YOU
In my case we have recently installed vmware 6.0 U3 that caused this problem
Your solution worked! FINALY, I have performed it a little bit and here is my recipe:
1. You may use putty so first enable SSH on affected host
2. Login to MyVMWARE and access the link https://my.vmware.com/group/vmware/details?downloadGroup=DT-ESXI60-EMULEX-BE2ISCSI-11411780&productI...
3. Extract zip, and all zip inside.
4. Find both VIB:
- EMU_bootbank_ima-be2iscsi_11.4.1178.0-1OEM.600.0.0.2494585.vib
- EMU_bootbank_scsi-be2iscsi_11.4.1178.0-1OEM.600.0.0.2494585.vib
COPY both VIB to affected host into /var/log/vmware AND NOT TO TMP LIKE SAYED IN README
5. Execute on each affected host:
- esxcli software vib install -v EMU_bootbank_ima-be2iscsi_11.4.1178.0-1OEM.600.0.0.2494585.vib
- esxcli software vib install -v EMU_bootbank_scsi-be2iscsi_11.4.1178.0-1OEM.600.0.0.2494585.vib
6. THE PROBLEM IS GONE even no need to restart the host
7. Option, you may apply this article to configure a persistent location VMware Knowledge Base
Have FUN !
I had this issue where the scratch location would not change (syslogs change worked fine) with HPE esxi 6.0 U3 (October Build), I upgraded to the February build (same 6.0 U3) and it fixed the issue
We spent a bit of time troubleshooting this issue and there may also be a bit of a GUI bug or interpretation of the logic behind the design may be causing incorrect understanding of how the ScratchConfig.CurrentScratchLocation is meant to display hen a new parameter is set.
i'm still yet to wrk out which one.
the change syslog.global path worked for us but the /scratch location in the GUI never changes.
for anyone who encounters this issue the KB article is a little confusing as it gives options when it should have a clear process so that you don't need to guess and waste time with multiple reboots.
here are the direct steps that worked for us (us being a VMware engineer and myself)
create a directory on persistent storage it could be a shared storage i.e. san or local disk in the following format .locker-hostname
in vCenter > hosts and clusters > configure > system > advanced system settings > edit > Syslog.global.logDir
enter in the following that corresponds to your [datastore] /path i.e [vsphere-01] /logs/.locker-esx09
in the same advanced options search for and edit > ScratchConfig.ConfiguredScratchLocation > remove all contents from this field > save > put host into maintenance mode > reboot
once the host has rebooted go and check the created log directory to conform that logs are now being deposited into the correct location on the datastore.
the path details for ScratchConfig.CurrentScratchLocation will always display /scratch but your logs should now be sent to the new path defined in "Syslog.global.logDir".
would love to hear that this has worked for others without the need of removing or updating drivers.
will report if anything changes in a few days otherwise if i haven't posted you can assume the solution has worked.
""Cheers
G
Hi guys,
is anyone aware if vSphere 6.7 will fix this issue? If yes I would rather wait a bit for 6.7U1 then upgrading the elxiscsi drivers on all hosts.
Thanks!
I believe it does.
In my scenario, we have HPE servers so I use the HPE OEM customised ESXi installer. Looking at the HPE drivers included in their 6.7 installer (https://support.hpe.com/hpsc/doc/public/display?docId=c04430318 ) it contains a newer driver (12.0.1108.0) than that mentioned here HPE Support document - HPE Support Center (11.4.1210.0) which I can confirm does fix the problem.