ESXi hosts show Not Responding after partial vCenter High Availability deployment due to routing conflict

search cancel

book

calendar_today

VMware vSphere ESXi

Multiple ESXi hosts transition to a "Not Responding" state in vCenter Server.
Attempts to manually reconnect the hosts result in the error: "The host is already managed by a different vCenter Server".
Virtual Machines remain operational on the data plane, but management operations are unavailable.
The vCenter Server is in a partial vCenter High Availability (VCHA) deployment state.
Network pings to the ESXi hosts are successful.

This failure is caused by a dual conflict originating from an incomplete or partial VCHA deployment:

Network Routing Conflict: A secondary network adapter (eth1) added for VCHA on the Active vCenter VM was assigned a default gateway. This creates asymmetric routing that disrupts UDP heartbeat traffic (Port 902) between the ESXi hosts and vCenter.
Management Lock Conflict: The incomplete VCHA configuration allowed the Passive node to intercept management locks. The "managed by another vCenter" error occurs because the Passive node's UUID competes for host management ownership.

To restore management connectivity, perform the following steps:

Restore Routing:
1. Edit settings for the Active vCenter VM.
2. Disconnect or remove the secondary network adapter (NIC 1 / eth1) that contains the conflicting default gateway.
Decommission VCHA:
1. Log in to the vSphere Client.
2. Completely destroy the partial VCHA configuration to release all management locks.
Restart Management Services:
1. Access the vCenter Server Appliance (VCSA) via SSH.
2. Run the command: service-control --restart vmware-vpxd vmware-vsphere-ui.
Reconnect Hosts:
1. Right-click the affected ESXi hosts in the inventory and select Reconnect.

If the issue persists, ensure no physical firewalls are blocking UDP 902 traffic. For further assistance, see Contact Broadcom Support.

thumb_up Yes

thumb_down No