Del nsx not working consolidated issues & checklist of stale component removal
search cancel

Del nsx not working consolidated issues & checklist of stale component removal

book

Article ID: 451192

calendar_today

Updated On:

Products

VMware NSX

Issue/Introduction

  • Host preparation hangs or fails at 48%.
  • NSX UI shows host status as "Orphaned" or "Failed."
  • nsxcli -c del nsx returns: Unable to clear DVS property com.vmware.nsx.vdl2.enabled: Status(bad0004)= Busy.
  • Stale kernel interfaces (vmk10, vmk50) persist despite uninstallation attempts.
  • DVS property com.vmware.common.opaqueDvs.status.component.vswitch is reported as down instead of the expected up.
    net-dvs | grep "com.vmware.common.opaqueDvs.status.component.vswitch"

com.vmware.common.opaqueDvs.status.component.vswitch = down , propType = CONFIG
  • Host preparation fails at approximately 48 percent when attempting to reprepare an ESXi host for NSX.
  • The host enters an orphaned or failed state within the NSX Manager user interface.
  • Manual uninstallation attempts via the del nsx command fail with a resource busy error impacting com.vmware.nsx.vdl2.enabled.
  • Stale kernel interfaces such as vmk10 and vmk50 persist despite uninstallation attempts.
  • The DVS property com.vmware.common.opaqueDvs.status.component.vswitch is reported as down instead of the expected up status.
  • When attempting to decommission or reprepare an ESXi host for VMware NSX, the standard manual uninstallation command nsxcli -c del nsx may fail to execute successfully. This failure typically manifests as a "Resource Busy" error (Status code: bad0004), specifically when the system attempts to clear Distributed Virtual Switch (DVS) properties such as com.vmware.nsx.vdl2.enabled.
  • This condition often occurs when the host is in an "Orphaned" state or when the automated uninstallation from the NSX Manager UI does not cleanly purge all artifacts. The persistence of stale kernel interfaces (e.g., vmk10, vmk50), active VTEP/spf/vdr ports, or incorrect runtime switch statuses (where com.vmware.common.opaqueDvs.status.component.vswitch is reported as down) prevents the uninstallation script from completing.
  • To return the host to a "Not Configured" state and allow for a clean re-preparation, a consolidated checklist of manual removal steps is required to purge these stale components from the ESXi host and the vCenter Server.

 

Environment

  • VMware NSX

Cause

  • When an ESXi host is removed directly from vCenter without first removing NSX, it can result in entries for that host to remain in the NSX database.
  • The repreparations issue is caused by stale NSX components (VMkernel interfaces and DVS properties) that were not cleanly removed during previous preparation attempts. Specifically, when com.vmware.common.opaqueDvs.status.component.vswitch is in a down state or categorized as a CONFIG property rather than RUNTIME, the NSX agent cannot properly manage the switch, leading to "Resource Busy" errors during cleanup.

Resolution

To return the host to a "Not Configured" state and allow for a clean re-preparation, a consolidated checklist of manual removal steps is required to purge these stale components from the ESXi host and the vCenter Server.

1. vCenter Operations:

Isolate the host.

First, you need to move the host out of the vSphere cluster to isolate it from active workloads.

  • Place the ESXi host into Maintenance Mode.

  • Select the host in vCenter and drag it out of the cluster, placing it at the Datacenter level.

2. NSX UI and API Cleanup:

Clear orphaned components.

Verify the host's status in the NSX Manager UI and clean up any stale components.

  • In the NSX UI, navigate to System > Fabric > Hosts > Other Nodes. The host should appear here.

  • Ensure the host is in a Not Configured state.

  • If the host is in an Orphaned state:

    • Use the NSX global search to find the host.

    • Verify there are no associated components attached to the host (e.g., logical ports, vDS topologies), except for open alarms.

    • If you find associated logical ports, delete them.

    • If you find a stale vDS topology, locate it and rerun the precheck to clear out the stale host.

  • Verify the transport node state via API:

GET https://<nsxmanager>/api/v1/transport-nodes/<tn-id>/state

(Note: Replace <Transport Node UUID> with the UUID reported in your error messages.)

  • The expected state is Object Not found. If it returns anything else (for NSX-T 3.2.x and 4.x), force the removal by running HTTP:
     
    DELETE https:///<nsxmanager>/api/v1/transport-nodes/<tn-id>?force=true&unprepare_host=false
If issue persists please follow the KB: unprepare host from NSX

3.ESXi Host Property Cleanup:

Command-line verification.

Connect to the ESXi host via SSH to manually verify and remove lingering NSX properties on the vDS.

  • Check if any of the following properties exist by running:

    net-dvs -l | grep com.vmware.nsx.kcp
net-dvs -l | grep com.vmware.nsx.spf
net-dvs -l | grep com.vmware.nsx.vdl2
net-dvs -l | grep com.vmware.net.portset.fc.enabled
net-dvs -l | grep com.vmware.net.portset.fc.mcast

     

  • If any of these return a value of true, remove the property using:

    net-dvs -u <property_name> -p hostPropList <vds_name>

  • Verify the vSwitch component status:

    net-dvs | grep "com.vmware.common.opaqueDvs.status.component.vswitch"

         Expected output: com.vmware.common.opaqueDvs.status.component.vswitch = up, propType = CONFIG

  • If the status is down or the propType is incorrect, fix it using:
    net-dvs -s com.vmware.common.opaqueDvs.status.component.vswitch=up -p hostPropList
4.Handle Busy Errors:

Advanced manual cleanup.

If you encounter the error Unable to clear DVS property com.vmware.nsx.vdl2.enabled: Status(bad0004)= Busy, follow these override steps. The below steps will also work in case unable to delete the VIBS.

  • Manually remove all VTEP VMkernel interfaces on the ESXi host:

    esxcli network ip interface remove --interface-name=vmk10
esxcli network ip interface remove --interface-name=vmk11
esxcli network ip interface remove --interface-name=vmk50

  • Find the ports used for the VTEP, vdrPort, and spfPort:

    net-dvs -l

       (Search the output for "VTEP". The port UUID will be listed just above it. Repeat this for all VTEPs.)

  • Manually remove those ports from the DVS:
    net-dvs -D -p <port_uuid> <switch_name>
  • Attempt to run del nsx again on the ESXi host.

  • If it still fails, force a hot swap of the CVDS to DVS:

    /usr/lib64/vmware/nsx-opsagent/bin/nsxcfg-vswitch -s
  • Run esxcfg-vswitch -l You will see an error with DVSPortset-X

  • Run vsish -e set /net/portsets/DvsPortset-X/destroy destroy to destroy the old DVS
  • Reboot the host, post a reboot this should convert the NSX Switch to DVS.

  • Run del nsx one more time to complete the removal.
    nsxcli -c del nsx
  • After execution, run the below . No VIBs should be returned. The host is now ready for a clean NSX preparation.
    esxcli software vib list | grep nsx

 

Additional Information

Powered by Wolken Software