Couple of things you can do
1) Check the DNS Settings on the host
2) Make sure port 80 is opened from host to vcenter
3) If vCenter is running on a Windows machine, other applications can be installed and use port 80, causing a conflict with EAM port tcp/80. So you to use different port for EAM
4) Hopefully there is no firewall between your host and vcenter.
5) Run these commands to get a better idea
Check the MTU settings esxcli network nic list
ping ++netstack=vxlan -I vmk3 184.108.40.206
6) Verify VIBS are properly installed
esxcli software vib get --vibname esx-vxlan
I have faced the same problem....i did the below steps:
- Check VDS that earlier nsx deployment is cleaned up [ Sometime, its created vds portgroup ,which you need to delete manually]
- Check name resolution is working.
Try it out again... else login to nsx server
- configure the terminal and show manager logs [post the error message]
Please verify the following things, either one of the following issue can cause this issue:
1. Connectivity issue:
Verify connectivity from NSX Manager to vCenter. Ping from NSX Manager to vCenter using both the IP address and the Fully Qualified Domain Name (FQDN). Check for routing or static information or for the presence of a default route in NSX Manager:
2. DNS Issue:
Verify NSX Manager can successfully resolve the vCenter DNS name. Ping from NSX Manager to vCenter with FQDN:
3. Firewall Issue:
If you have a firewall between NSX Manager and vCenter, verify it allows SSL communication on TCP/443 and port 80 (also allow ping for connective checks).
4. NTP issue:
Verify that actual time is synced between vCenter and NSX Manager.
5. User permission issue:
Registered user to vCenter or Lookup service must have administrative rights.
Try to work with default administrator user: email@example.com
All good suggestions. Don't forget to check your VTEP IP Pool and make sure you have IPs available for the VTEP on your new host.
Sometimes IPs get stuck and they don't get released from the pool when I was swapping out host from the NSX cluster. This happened to me once. We had to use REST API to release the IP for the new host.