All ESXi hosts managed by a specific vCenter Server were observed to enter a “Not Responding” state approximately every 60 seconds and then immediately return to a Connected state.
This recurring disconnection cycle caused intermittent host communication loss, frequent alerts in monitoring systems, and occasional failures in vSphere operations that relied on stable host connectivity.
Upon investigation, it was observed that heartbeat packets were not leaving the ESXi hosts on UDP port 902, which is the standard communication channel used by vCenter to maintain the vpxa heartbeat.
Packet captures taken directly on the host confirmed that no outbound traffic was generated on port 902 during the disconnection intervals.
Network validation confirmed that:
Port 902 connectivity between vCenter and the ESXi hosts was functional when tested manually.
No firewall rules were blocking the traffic path in either direction.
The issue originated before the packets left the ESXi host, indicating a local configuration problem rather than a network-layer fault.
Further review of the vpxa logs on the affected hosts revealed repeated entries showing that vCenter was continuously pushing an incorrect port configuration to the vpxa agent:
YYYY-MM-DDTHH:MM:SS.093Z verbose vpxa[25115670] [Originator@6876 sub=VpxaConfigStore opID=HostSync-host-########] Successfully updated vpxa root config object 'esx.services.vpxa_solution_user_config' for key 'server_port' with value '120'
This confirmed that the vpxa agent was being reconfigured to use UDP port 120 instead of the correct port 902, preventing the heartbeat packets from being sent and causing the recurring “Not Responding” behavior.
vCenter 7.x, 8.x
ESXi 7.x, 8.x
The issue was traced to an incorrect heartbeat UDP port configuration within the vCenter Server file vpxd.cfg.
This configuration file defines the communication parameters for the heartbeat exchange between the vpxa agent on ESXi hosts and the vpxd service on vCenter.
In the affected environment, the <udp-port> value under the <heartbeat> section was incorrectly set to 120 instead of the default 902, as shown below:
When this misconfiguration exists in vpxd.cfg, vCenter continuously propagates the incorrect UDP port value (120) to all connected ESXi hosts during synchronization of the vpxa configuration.
As a result:
The vpxa agent on each ESXi host attempts to use UDP port 120 for its heartbeat communication with vCenter.
Since vCenter is actually listening on port 902, these heartbeat packets fail to reach their destination.
Consequently, vCenter stops receiving heartbeats and marks the host as Not Responding.
When the next sync interval occurs, the vpxa agent re-establishes temporary communication, and the host returns to a Connected state.
This cycle repeats approximately every 60 seconds, causing continuous state flapping.
To validate this behavior, the configuration on one of the affected hosts was examined using the following command:
The output confirmed that the UDP port was incorrectly set to 120.
configstorecli config current get -c esx -g services -k vpxa_solution_user_config
Even when the port was manually corrected to 902 on the ESXi host, the value reverted back to 120 after a few minutes, as vCenter continued to push the incorrect configuration during synchronization.
The UDP port value must be corrected in vpxd.cfg on the vCenter Server, ensuring that vCenter pushes the correct configuration to all managed hosts.
<heartbeat>
<notRespondingTimeout>120</notRespondingTimeout>
<udp-port>902</udp-port>
</heartbeat>
service-control --stop vpxd
service-control --start vpxd
configstorecli config current get -c esx -g services -k vpxa_solution_user_config
Troubleshooting an ESXi host in a “Not Responding” / “Disconnected” state — general guide for host-agent communication breakdowns, network validation, and recovery steps.
ESXi hosts marked as Not Responding following an upgrade — describes a scenario post-upgrade where hosts repeatedly lose connectivity and how certificate / agent resets may trigger that.
ESXi host disconnects intermittently from vCenter Server — focuses on lost UDP heartbeats (port 902) and network-related causes leading to the host being marked “Not Responding.”
Understanding the difference between Not Responding and Disconnected ESXi hosts — useful for clarifying semantics and how each state is handled.