ESXi Hosts Entering “Not Responding” State Every 60 Seconds Due to Incorrect UDP Port Configuration in vpxd.cfg
search cancel

ESXi Hosts Entering “Not Responding” State Every 60 Seconds Due to Incorrect UDP Port Configuration in vpxd.cfg

book

Article ID: 414524

calendar_today

Updated On:

Products

VMware vSphere ESXi VMware vCenter Server

Issue/Introduction

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.

 

Environment

vCenter 7.x, 8.x

ESXi 7.x, 8.x 

Cause

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:

 <udp-port>120</udp-port>

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.

 

Resolution

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.

  • Step 1: Access vCenter Server Appliance
    • SSH into the vCenter Server Appliance (VCSA) using the root account.
    • Enable shell access if prompted by running:
    • shell

 

  • Step 2: Edit the vpxd.cfg File
    • Open the vpxd configuration file:
    • vi /etc/vmware-vpx/vpxd.cfg
    • Locate the <heartbeat> section.
    • Modify the <udp-port> value from 120 to the correct port 902:
      • <heartbeat>

            <notRespondingTimeout>120</notRespondingTimeout>

            <udp-port>902</udp-port>

        </heartbeat>
    • Save and exit the file (:wq in vi).

 

  • Step 3: Restart vCenter Services
    • Restart the vCenter services to apply the updated configuration:
    • service-control --stop vpxd

      service-control --start vpxd

 

  • Step 4: Validate the Configuration
    • After services restart, connect to one of the affected ESXi hosts and run:
    • configstorecli config current get -c esx -g services -k vpxa_solution_user_config
    • This should remain to be 902 now. 

Additional Information

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.