Bear with me, this is my first day w/ this software as I normally work w/ Hyper-V. For the life of me I cannot get the AVAGO LSI storage authority to log into my host to display info. I get the following "Error Code:65537 : Logon failure: unknown user name or bad password" I've confirmed correct credentials to log into host.
I did get it to work once oddly and it hasn't since. What I do notice is in ESXi under Host | Monitor | hardware | storage | everything but memory is Unknown.
Hardware: Lenovo Thinkserver TS460
RAID controller: embedded MR9340-8i
Things I have tried/done:
Name = 500605B00DD3F6E0
CreationClassName = LSIESG_MegaRAIDHBA
What is installed:
GUEST OS (2019 Server)
Any input would be greatly appreciated.
And now it seems after a second attempt at logging in I get: Error Code:65538 : No write permissions for this user
I am logging in as root (The only account currently set up).
I tried to google this but got nearly nothing of any use.
I was able to get this working today. I thought I would share exactly what I did:
I started with an older SuperMicro-based system (X9DRH-7TF) with an embedded LSI 2208 RAID chip. I installed VMware-provided ESXi 6.7U3.
After installation, I enabled SSH and used it to install StorCLI 1.23.02 (from 1.23.02_StorCLI.zip) via the following command:
esxcli software vib install --no-sig-check -v /vmfs/volumes/storage/path/vmware-esx-storcli-1.23.02.vib
I don't think StorCLI is necessary for the rest, but I *really* like having it, so I installed it first! Once installed, I tested it with the following command:
/opt/lsi/storcli/storcli show ctrlcount
It showed one controller. Great!
There were reports that nothing needed to be installed on the ESXi side, but this is *incorrect*. I found that if I next installed the LSI Storage Authority on a VM, it would not work. I was able to discover the ESXi system, but when I tried to log in I got Error 65537: Login failure.
Actual next step: make sure you have lsiprovider installed. First, verify that you don't, from SSH command line:
esxcli software vib list | grep lsi
There were several LSI lines (for the drivers) but there was *not* one for lsiprovider. Fine, now we'll install one. The latest I could find was 500.04.V0.73-0002 from VMW-ESX-6.5.0-lsiprovider-500.04.V0.73-0002-offline_bundle-12787245.zip. I installed it with the following command:
esxcli software vib install --no-sig-check -v /vmfs/volumes/storage/path/vmware-esx-provider-lsiprovider.vib
It installed, but requires a reboot to continue. After rebooting and logging back in via SSH, I reran the vib list command above and saw lsiproviders.
I then installed the LSI Storage Authority software on a Windows VM. That VM was on the same subnet as my ESXi box, and the ESXi host was automatically added to LSA. One problem I had: the computer name it uses is what it gets from its query of ESXi. In my test environment here, that name does *not* resolve. So connecting to that host did not work. However, I used the Manual Discovery with the ESXi system's IP address and was able to connect to it successfully.
From there, I was able connect to the host using proper credentials from the ESXi side (e.g. root, and the password I used to install ESXi). I could see the controller and array status, make changes, etc.
As an aside: I tried to make the Email alert portion of LSA work. If I used our actual production SMTP server, testing the email configuration would *crash* the LSA interface! If I used a test (internal) SMTP server it would work, but that doesn't do me that much good. I'm not real thrilled with the idea of the LSA being responsible for monitoring and alerting anyway: I use Zabbox and storcli to check on the status of the array instead.
In any case, this will get a brand-new ESXi 6.7U3 box with an LSI 2200-series controller connected to LSA so you can see the status of your array as well as make changes. I hope it helps save someone some time...
Probably my issue is the same with yours.
When I try to login with my correct credentials, the webpage would freeze for like 55 seconds, before returning the error message "Error Code:65537 : Logon failure: unknown user name or bad password". On the contrary, if I intentionally use a wrong password, the webpage would return the error message without any delay.
This leads to my guess that it's actually just a server timeout problem instead of wrong login info.
After a few configurations on the ESXi server, I think I have fixed the problem. Here is a screenshot summary of what I did.
What I did was following the LSA user guide 2.0 page 36 "Increasing the Memory Limit of the Host Hardware RAID Controller" and page 37 "Configuring the Provider on ESXi Servers ".
I'm not sure which one actually solved my problem. My guess would be that increasing the memory limit is the key. I would say that Error Code 65537 is a general error. When the RPC times out on the ESXi server, probably due to insufficient resources, the webpage just pops this generic error message.
Hope this helps!
Update: starting with ESXi 7.0U2, updates to sfcb are no longer preserved between reboots. Follow this link to make modifications to the config files: https://kb.vmware.com/s/article/82638
Also another option to temporarily restore connections to the LSIprovider from LSA is to restart the WBEM service:
This should give you around 3 min of good connection time (just enough time to monitor the virtual drive health).
Thanks for your advise. My ESXi 6.7U3 has the same problem, and I didn't know how to solve it. However, I encountered a problem during the modification of the file 'providerTraceLog.properties'. Here are my attempts:
1. Stopped the service sfcbd-watchdog, and put my ESXi into maintenance mode;
2. Started the SSH service, and log-in with Windows Terminal as root;
3. cp providerTraceLog.properties providerTraceLog.properties.bak;
4. vi providerTraceLog.properties, and tried to insert a line 'LSA=true';
5. :wq ...... (This is where the problem exists.)
I was kept on advised that 'Operation not permitted', I even tried 'chmod 777' and failed too. So, could you please advise me how you successfully modified that file?? Thank you.
I ran into the same problem after upgrading to 7.0U2.
The entire /etc is locked down and modifications will not be carried over reboots.
It seems like we are out of luck. I have reverted back to restarting wbem (at the bottom of my previous post) whenever I want to monitor the drive health.
Perhaps at some point I'll submit a ticket to VMWare/Boardcom and raise the issue with them.
Good news! I eventually managed to modify the locked file. You may follow these steps to see if they would work for you too:
1. cp providerTraceLog.properties ABC ;
2. vi ABC ; And insert the line;
3. :wq (then I succeeded);
4. cp -f ABC providerTraceLog.properties;
Hope this helps!
------- Edit -------
Although the aforesaid method is able to modify that locked file for me, But, that won't persist across a reboot.....
Hi everyone, with these steps the monitoring seems to work correctly, my configuration:
Supermicro X10DRH-CT onboard controller Broadcom 3108 SAS3
Controller ID: 0 AVAGO 3108 MegaRAID
Firmware Version: 4.680.00-8519
Driver Version: 7.718.02.00
I updated host VMware version ESXi-7.0U3d and native driver lsi-mr3 is 7.718.02.00-1vmw.703.0.20.19193900
Installed lsiprovider 700.00.V0.82-0001 https://docs.broadcom.com/docs/VMW-ESX-7.0-lsiprovider-00.82.V0.01.zip
Installed vmware-storcli64 007.2007.0000.0000-01 https://docs.broadcom.com/docs/007.2007.0000.0000_Unified_StorCLI.zip
Enable CIM Server (sfcbd-watchdog) and slpd services
with this guide https://www.dell.com/support/kbdoc/it-it/000190499/powerpath-ve-sfcbd-terminated-after-powerpath-7-2... i added “provMemOveride: hhrc=100”
so I added in /etc/rc.local.d/local.sh above the "exit 0" statement:
echo "provMemOveride:hhrc=100" >> /etc/sfcb/sfcb.cfg
esxcli system wbem set -e 0
esxcli system wbem set -e 1
Guest OS Windows 10 i installed LSI Storage Authority v007.020.014.00 https://docs.broadcom.com/docs/007.020.014.000_LSA_Windows.zip
edit the hosts file in C:\Windows\System32\drivers\etc
for automatic discover server i added ip address host Vmware ESXI and corresponding dns name
I am trying to get my Windows based LSA Storage Authority GUI to talk to a recently upgraded VMWARE 7.0.3 (was at 6.7U3)'s LSI 9361-8i controller. I have been all through this thread and many others gathering information and troubleshooting this to death al afternoon. I have the sfcbd-watchdog (CIM) memory issue resolved which got me from not being able to authenticate to being able to but now I am stuck with the CIM apparently reporting back to my Windows LSA client with error 5054: Repository Not Initialized and I can NOT get past this. On the VMWARE 7.0.3 I have most recently (7.0 compatible) versions of everything stated here: lsiprovider, vmware_lmw (the local LSA) and even storcli64. Here is the vib list on my server:
BCM-vmware-lwm 008.006.010.000-01 BCM VMwareAccepted 2023-08-09
lsiprovider 700.00.V0.81-0001 BCM VMwareAccepted 2023-08-09
vmware-storcli64 007.2612.0000.0000-01 BCM PartnerSupported 2023-08-09
lsi-mr3 7.718.02.00-1vmw.703.0.20.19193900 VMW VMwareCertified 2023-08-09
lsi-msgpt2 20.00.06.00-4vmw.703.0.20.19193900 VMW VMwareCertified 2023-08-09
lsi-msgpt35 19.00.02.00-1vmw.703.0.20.19193900 VMW VMwareCertified 2023-08-09
lsi-msgpt3 17.00.12.00-1vmw.703.0.20.19193900 VMW VMwareCertified 2023-08-09
lsuv2-lsiv2-drivers-plugin 1.0.0-12vmw.703.0.50.20036589 VMware VMwareCertified 2023-08-09
When I start LSAD and check syslog I can verify that it is indeed talking to the locally connected 9361-8i controller and pulling all the hardware and virtual volume configs (sent out in great detail to /var/log/syslog.log). Storcli64 of course talks to it just fine.
The problem _seems_ to be that the VMWARE CIM (sfcbd) is not linking into the lsiprovider somehow to get this info resulting in blank results being sent back to the LSA Storage Manager client in Windows. Everything is running: LSAD, sfcbd-watching, slpd.
Ultimately I'd like to get SNMP working as we run ZABBIX here as our monitoring platform the goal is to actively catch any degraded volume conditions in real time so we can address them. I have email configured but without pulling a disk I can't tell if that is working.
I would really like to get the Windows LSA SM interface working too. Any ideas? Thanks!
Are you a FAN of <Friends>? What a good nickname...... Let's get back to the subject, my Windows LSA talks to the LSIProvider well, and you may refer to the attached screenshot for details. 9364-8i actually is similar to 9361-8i very much.
To my experience, only 3 stuffs are necessary, i.e.: SMIS/CIM Provider, Driver & LSA. And here is the CIM Provider that I'm using, and I think this the most important one:
SMIS Providers MR 7.13 Version:00.77.00.04
If you are sure that everything is good with you ESXi server, maybe you should double-check your Windows firewall settings carefully to see if any rule that may fail the LSA communications went wrong.
if somebody meet 5054:Repository Not Initialized issue
and check "read me ", it wall list the supported controller,eg:
Supported MegaRAID Controllers
MegaRAID SAS 9560-8i
MegaRAID SAS 9560-16i
MegaRAID SAS 9580-8i8e
MegaRAID SAS 9480-8i8e
MegaRAID SAS 9460-8i
MegaRAID SAS 9460-16i
MegaRAID SAS 9440-8i
MegaRAID SAS 9361-16i
MegaRAID SAS 9361-8i
MegaRAID SAS 9361-4i
MegaRAID SAS 9341-8i
MegaRAID SAS 9341-4i
MegaRAID SAS 9380-8e
MegaRAID SAS 9380-4i4e
MegaRAID SAS 9361-24i
MegaRAID SAS 9380-8i8e
my raid card is 9364-8i (waistcoat of 9361-8i), so the last supported LSA is 007.021.006.000_LSA_Windows.zip (you can find it in "archive" not "current")
after install this version , problem is gone
For people who are really stuck at this. I think I might have figured out why...
First off, make sure you ALWAYS read the README files. There is a big chance that the driver/LWA/SMIS provider that you downloaded does not support your RAID card.
Secondly, do not try to always install the latest stuff from Broadcom. It's highly likely that what you want is in the archive. Your device is likely to be supported by an older version.
Finally, make sure everything has the same version. Make sure you install the same version of LWA/SMIS and LSA manager (client side, such as windows or linux). If your versions mismatch, you will get the 5054 error. Pay absolute attention to having everything matched versions.