NSX Host preparation fails with an "Host configuration: Found security-only non-CVDS on the host" message

Products

• VMware NSX
• VMware vDefend Firewall

Issue/Introduction

• NSX host preparation fails at the "Applying NSX switch configuration" stage with the following error in the UI

Transport Node Errors
Host configuration: Found security-only non-CVDS on the host.;

• The following error would be registered in the NSX Manager /var/log/proton/nsxapi.log 

  ERROR L2HostConfigTaskExecutor5 TransportNodeAsyncUtils 75770 FABRIC [nsx@6876 comp="nsx-manager" errorCode="MP8817" level="ERROR" subcomp="manager"] Some error occured when configuring host switch on host: Found security-only non-CVDS on the host.;
  
  ERROR L2HostConfigTaskExecutor5 TransportNodeAsyncUtils 75770 FABRIC [nsx@6876 comp="nsx-manager" errorCode="MP8817" level="ERROR" subcomp="manager"] Some error occured when configuring host switch on host: Found security-only non-CVDS on the host.;
  
  ERROR L2HostConfigTaskExecutor5 TransportNodeAsyncServiceImpl 75770 FABRIC [nsx@6876 comp="nsx-manager" errorCode="MP8700" level="ERROR" subcomp="manager"] Found security-only non-CVDS on the host.; com.vmware.nsx.management.switching.common.exceptions.SwitchingException: null

• On the ESXi host, stale NSX properties from a previous install remain, even when there are no NSX VIBs.
  

  [root@ESXi:~] net-dvs -l | grep -E "^switch|com.vmware.nsx.*.enable|com.vmware.common.alias|com.vmware.common.nsxUplink"
  switch ## ## ## ## ## ## ## ## - ## ## ## ## ## ## ## ## (cswitch)
   com.vmware.common.alias = <DVS_name> ,         propType = CONFIG
   com.vmware.nsx.<property>.enabled = true ,         propType = CONFIG

  Note:
  cswitch represents a non-NSX prepared switch for DVS 7.0.3 and above.
  vswitch represents an NSX prepared switch.
  
  Some properties show enable, some enabled.
  Stale NSX properties may include (non-exhaustive):
  
  • com.vmware.nsx.kcp.enable
  • com.vmware.nsx.spf.enabled
  • com.vmware.nsx.vdl2.enabled
  • com.vmware.nsx.vdsSecurity.enabled
  • com.vmware.common.nsxUplink

Environment

VMware NSX 4.2.x

Cause

Improper uninstallation of the NSX VIBs on the ESXi host may lead to stale entries. The hosts with stale entries will fail to prepare for NSX.

Resolution

This is a condition that may occur in a VMware NSX environment.

Workaround:

1. Verify the presence of stale entry. A few scenarios when the property is considered stale are:
   • For DVS version 7.0.3 and above, If the user sees "com.vmware.nsx.<property>.enabled = true" for a "cswitch".
   • If you see "com.vmware.nsx.<property>.enabled = true" on a host with NO NSX VIBs.
     To check for NSX VIBs:

     [root@ESXi:~] esxcli software vib list | grep -i nsx
     [root@ESXi:~]

     Note: If the above command gives no output, then no NSX VIB is present on the ESXi host.
     
     
2. Remove the stale NSX properties:
   This command should be run when the host is not prepared for NSX.  If the host is still prepared the net-dvs -u command may fail.
   The error may state "ioctl failed: Invalid argument".  Simply remove the host from the cluster and verify that the NSX VIBs are not installed.
   

   [root@ESXi] net-dvs -u com.vmware.nsx.<property>.enabled -p hostPropList <DVS_name>

   Note: Replace <property> with the stale NSX property previously identified and <DVS_name> with the vSwitch alias.
             Some properties show enable, some enabled.
   
   Example of commands to run, note the command for nsxUplink is a different format to the others:
   
   net-dvs -u com.vmware.nsx.kcp.enable -p hostPropList <DVS name>
net-dvs -u com.vmware.nsx.spf.enabled -p hostPropList <DVS name>
net-dvs -u com.vmware.nsx.vdl2.enabled -p hostPropList <DVS name>
net-dvs -u com.vmware.nsx.vdsSecurity.enabled -p hostPropList <DVS name>

net-dvs -u com.vmware.common.nsxUplink -p globalPropList <DVS name>
   
   
3. Restart hostd with:
   
   /etc/init.d/hostd restart
   
   
4. Re-attempt the installation of NSX on the ESXi host.

Note: If the stale properties reappear on the VDS after a host reboot or after restarting VPXA, this may indicate that the properties are stuck in the vCenter database and are being reapplied to the host during initialization. If this behavior is observed, please open a Support Request with Broadcom for assistance with reviewing and cleaning up the vCenter database entries. For more information, refer to this KB