6.5 Fix does not resolve issue on 6.7. sfcbd-watchdog is running and port 5989 is open.
Still get this error.
Hardware polling failed: Polling of chassis (CIM_Chassis class) failed. The underlying connection was closed: An unexpected error occurred on a send.
We have 3 ESXi 6.7 host and soon will have another one.
Has anyone have a solution?
We've upgraded to 6.7 and still have hardware issues as well. My Virtualization Engineers say everything's clean on their end and we still have faulting hardware in Orion. It rears its head after they perform hardware maintenance, and that behavior has been consistent across a couple ESX hosts over the past few weeks. The fix that was working with 6.5 to clear the logs on the VMWare side isn't working with 6.7 it seems. I opened a case with SW support last night. Frustrating.
I was having issues monitoring esx 6.7 hosts with n-able (nCentral). This is what I had to do to resolve the issue.
ssh to the esx 6.7 host, logon as root
esxcli system wbem set --enable true
vim-cmd hostsvc/advopt/update Config.HostAgent.plugins.solo.enableMob bool true
edit the sfcb.cfg file by running command:
add the following lines:
esc :wq Enter to save the file
In NCentral run the discovery again using their procedure:
It is solved for me
The problem was, since v6.7 -> TLS is disabled by default
i had to edit /etc/sfcb/sfcb.cfg and add the line: enableTLSv1: true
saved the file and restarted the service with: /etc/init.d/sfcbd-watchdog restart
Per Solarwinds suppprt, this issue can be resolved by either enabling TLS1.0 on ESXi 6.7 (not recommended) or disabling TLS1.0 and 1.1 on the Solarwinds Pollers.
i was told by support to enable TLS on 6.5 version but thats not working correctly on all ESX hosts... regd disabling of TLS on Solarwinds Pollers, i havent tried yet...
for now we are relying on iLO monitoring of each host for hardware health...
if you do succeed by using any option, then please let me know...
we dont see the TLS fix working on all hosts as the changes are getting reverted back to default on ESX host... not sure if 6.7 has already resolved this issue...
why is TLS needed here?
And were these changes recommended by VMWare? And did this solve your hardware polling issue for all ESX?
We have more than 50 ESX servers where we are facing issues and currently doing hardware monitoring via ILO which is using up additional licenses...
TLS is needed because the connection to the servers are on a secure transport layer.
Thats why port 5989 is needed. Its for HTTPS.
I don't know why solarwinds is not using HTTP (port 5988) or if this is configurable...
Since SSLv3 is not safe anymore vmware recommends to disable this. (default on v6.7)
The only choice now to establish a secure connection is by using TLS.
You can try this yourself by using the cimwalk tool found in the solarwinds installation folder.
Here is the Article about this tool: How to run a CIM walk against a VMware ESX Server VM - SolarWinds Worldwide, LLC. Help and Support
we just tested this in one of the dev host and it worked fine... able to see the hardware health now...
Still getting it validated with the team to ensure it doesnt affect the prod systems in any way.. will confirm back...
Hi I have applied this on one ESX server where we enabled the TLS as suggested and from 1 week i do not see any issue...we will soon apply this for all our hosts..
And another update which i got from my VMware Team- There is a resolution from VMware end as well but it requires an upgrade to patch U1 or something... it seems they have resolved it in that release...
Just to update on this... the setting is not working for all hosts and its getting overwritten i guess.. hence i would recommend to work with your tech teams, discuss and then enable...
for now we are taking the hardware monitoring via ILO...
i remember checking port 5989 but that was showing open... so additionaly TLS needs to be enabled on ESX level?
and was this setting change verified with VMware OR you just changed it and tested?
SolarWinds solutions are rooted in our deep connection to our user base in the THWACK® online community. More than 150,000 members are here to solve problems, share technology and best practices, and directly contribute to our product development process. Learn more today by joining now.