SNMP service fails to start on ESX host with the following error in /var/run/log/netsnmpd.log: "load_vds_switches: no component id returned"

Products

• VMware vSphere ESXi

Issue/Introduction

When attempting to start or restart the SNMP service (netsnmpd) on an ESXi host, the service fails to start and following symptoms are observed: 

• Executing /etc/init.d/snmpd restart completes without any immediate shell errors: 
  /etc/init.d/snmpd restart
Stopping netsnmpd by administrative request...
netsnmpd is not running.
Starting netsnmpd...
setting up resource reservations.
opening firewall port(s) for notifications.
link local address.
link local address is blank set '-' as a place-holder.
snmp firewall rule set to true

• Checking the service status immediately afterward via /etc/init.d/snmpd status reports that netsnmpd is not running:
/etc/init.d/snmpd status
netsnmpd is not running
  
  
• Reviewing the /var/run/log/netsnmpd.log reveals a rapid crash loop during the daemon startup phase, containing the following signature errors: 
  YYYY-MM-DDTHH:MM:SS -ERROR netsnmpd 15373053 [esx@4413] 4 of 4. Testing Log Levels - LOG_ERR
YYYY-MM-DDTHH:MM:SS -CRITICAL netsnmpd 15373053 [esx@4413] END Log Level Calibration
YYYY-MM-DDTHH:MM:SS -ERROR netsnmpd 15373053 [esx@4413] load_vds_switches: no component id returned for ifIndex 5, bridge 'DvsPortset-0', ignored
YYYY-MM-DDTHH:MM:SS -ERROR netsnmpd 15373053 [esx@4413] load_vds_switches: no component id returned for ifIndex 6, bridge 'DvsPortset-1', ignored
YYYY-MM-DDTHH:MM:SS -INFO netsnmpd 15373140 [esx@4413] netsnmpd is not running

• The ESXi host's vsantraceFailover ramdisk may currently be, or was recently, at 100% capacity due to an accumulation of old, compressed vsantrace.zst logging files.

Environment

VMware vSphere ESX

Cause

This issue is caused by a cascading architectural failure initiated by a full vsantraceFailover ramdisk.

Core ESXi management daemons, primarily hostd, rely on temporary filesystems to write state files and update internal run-time state caches. When the ramdisk reaches 100% capacity, hostd is unable to properly commit updates to its runtime maps. This results in a corrupted in-memory representation of the host's networking topology, specifically the vSphere Distributed Switch (e.g., DvsPortset-0 and DvsPortset-1).

When the netsnmpd service initializes, it queries hostd to pull the local networking topology and populate its Management Information Base (MIB) framework. Because hostd passes an invalid or blank component ID mapping for the distributed switches, the SNMP service encounters an unhandled parsing exception, panics, and enters a terminal crash loop.

Resolution

To remediate the current state and restore the SNMP service, the host's management agents must be restarted. This forces hostd to flush its volatile memory state, drop the invalid distributed switch mappings, query the VMkernel directly for a clean hardware/software inventory, and reconstruct a healthy object schema.

Follow these steps to apply the fix:

1. Ensure that the vsantraceFailover ramdisk has been cleared of old .zst files to free up space so the agents can function properly.
2. Place the affected ESXi host into Maintenance Mode.
3. Connect to the ESXi host via SSH as root.
4. Cycle the management agents sequentially by executing the following commands:
   • /etc/init.d/hostd restart
   • /etc/init.d/vpxa restart
   • /etc/init.d/snmpd restart
5. Verify that the SNMP service successfully parsed the networking stack and is actively running:
   • /etc/init.d/snmpd status
6. Exit Maintenance Mode on the ESXi host.