Some time ago I was having an issue putting a host back into service in an NSX environment. In Log Insight, and in the /var/log/netcpa.log I was seeing errors similar to the following:
2018-05-26T11:07:50.486Z [FFD53B70 error 'Default'] SSL handshake failed on 126.96.36.199:0 : error = SSL Exception: error:140000DB:SSL routines:SSL routines:short read 2018-05-26T11:07:55.545Z [FFD12B70 error 'Default'] SSL handshake failed on 188.8.131.52:0 : error = SSL Exception: error:140000DB:SSL routines:SSL routines:short read 2018-05-26T11:08:00.600Z [FFD12B70 error 'Default'] SSL handshake failed on 184.108.40.206:0 : error = SSL Exception: error:140000DB:SSL routines:SSL routines:short read
Browsing through VMware’s archive, I came across KB2151089, very similar to the issue I was having, however upgrading to NSX 6.3.5 was not an option at the time. I remembered a similar issue at my previous workplace, and dug through my evernote archive to find my notes.
Before we continue, this should go without saying, but your milage may very, and I’d recommend opening a ticket with VMware’s GSS. At the very least you should test this process out in a lab.
These steps outlined here will resolve the issue. Keep in mind at this point, the host is not in production, and currently is in maintenance mode:
- Determine if the NSX controllers are connected by logging into the ESXi host, and running the following commands:
# esxcli network ip connection list |grep 1234
— and —
# esxcli network ip connection list |grep 5671
- Next, log into the NSX appliance and backup the config. While the config backup is taking place, get the ESXi host mob id from the vCenter mob page https://<vcsa-fqdn>/mob
- select the link for the ‘root folder‘, eg. group-d1
- select the link for the ‘child entity‘ eg. datacenter-2
- select the link for the ‘host folder‘ eg. group-h4
- select the link for the ‘child entity‘ eg. domain-c7
- Now locate the ‘host‘ and find the host-xxxx value. eg: host-1234
- After the NSX backup is complete, ssh into the NSX manager. Root access to the appliance will be needed, so at the command prompt:
- Enter ‘en‘ and the enter the ‘admin’ password
- Enter ‘st en‘ and enter the following password: IAmOnThePhoneWithTechSupport
- Log into the sql prompt
# psql -U secureall secureall=#
- Issue the following command to verify that there is a record associated with the host mob ID. Below is an example using host-1234
# select host_uuid,node_uuid,thumbprint from vnvp_hot_key where host_uuid='host-1234';
host_uuid | node_uuid | thumbprint -----------+--------------------------------------+------------------ host-1234 | a2a68660-515e-4f87-811d-306c54b0b2e8 |AD:58:C0:84:FF:DF: 5E:95:50:B7:63:2E:3F:B2:67:22:56:F7:DC:9B (1 row)
- Next, in vCenter move the host to an isolation cluster. We will need to validate the NSX vibs installed by running the following command on the host:
# esxcli software vib list |grep -E 'esx-dvfilter-switch-security|vsip|vxlan'
esx-dvfilter-switch-security 6.3.1-0.0.5124716 VMware VMwareCertified 2017-02-28
esx-vsip 6.3.1-0.0.5124716 VMware VMwareCertified 2017-02-28 esx-vxlan 6.3.1-0.0.5124716 VMware VMwareCertified 2017-02-28
- Remove the NSX vibs with the following commands:
# esxcli software vib remove -n esx-vxlan
# esxcli software vib remove -n esx-vsip
# esxcli software vib remove -n esx-dvfilter-switch-security
- Returning to the NSX terminal window, now delete the record using the secureall=# prompt. Using ‘host-1234’ as an example.
# delete from vnvp_host_key where host_uuid='host-1234'; DELETE 1
- Reboot the ESXi host. Once the host has rebooted, put the host back into the proper cluster. To be safe, I would temporarily turn down DRS (move slider left), and exit maintenance mode.
- We can validate that the host looks proper in vSphere web UI: ‘Network & Security -> Installation -> Host Preparation Tab‘ .
- Click the ‘Resolve‘ link next to the cluster name
- Once the tasks are all completed you can run the ‘esxcli software vib list….‘ command again to see that the three vibs have been installed.
- Test that the vxlan network is functioning on the host.
- Verify that the SSL Exception is no longer showing in the /var/log/netcpa.log.
- If there are no errors, then the host is all set to be put back into service.