The hardware health status monitoring is currently unreliable and is not being displayed

Products

• VMware vSphere ESXi

Issue/Introduction

Symptoms:

• The hardware health status monitoring is currently unstable and the status is not being displayed.
• Attempts to reset the sensors and clear the event log have not resolved the issue.
• In the syslog.log, entries similar to the following are observed:

yyyy-mm-ddThh:mm:ss.Z sfcb-vmware_base[1038465]: TIMEOUT DOING SHARED SOCKET RECV RESULT (1038465)
yyyy-mm-ddThh:mm:ss.Z sfcb-vmware_base[1038465]: Timeout (or other socket error) waiting for response from provider
yyyy-mm-ddThh:mm:ss.Z sfcb-vmware_base[1038465]: Header Id (380439) Request to provider 141 in process 5 failed. Error:Timeout (or other socket error) waiting for response from provider
yyyy-mm-ddThh:mm:ss.Z sfcb-vmware_base[1038465]: Dropped response operation details -- nameSpace: root/cimv2, className: OMC_RawIpmiSensor, Type: 0

• Note: The preceding log excerpts are only examples. Date, time, and environmental variables may vary depending on your environment.

Environment

• VMware vSphere ESXi 6.0

Cause

• This issue occurs because the sfcb-vmware_base process is waiting for a response from another provider and crashes due to a timeout.

Resolution

This is a known issue affecting VMware ESXi 6.0, currently there is no definite resolution.

Workaround:

• To mitigate the issue, increase the memory pool size for the process that is running out of memory. Follow these steps:
  • Stop the sfcbd service with the command:
    • /etc/init.d/sfcbd-watchdog stop
  • Update the memory allocation using the command:
    • vsish -e set /sched/groups/<groupid>/memAllocationInMB minLimit=0 shares=1000 max=200
      • (Replace <groupid> with the group IDs for both sfcb_aux and sfcb.)
  • Restart the sfcbd service with:
    • /etc/init.d/sfcbd-watchdog start
  • Please note this change is not persistent and will reset to default after a host reboot.