This post replaces the unsafe package-removal command that appeared in my older article about removing stale NSX packages from an ESXi host. Broadcom now documents a clear distinction between removing NSX through its management workflow and cleaning up VIBs that remain afterward.

Warning: Do not manually remove individual NSX VIBs with esxcli software vib remove. Broadcom identifies that method as unsupported. It can break distributed-switch state, disconnect host networking, and in some failure cases leave reimaging as the recovery path.

When This Procedure Applies

Use this workflow for the documented stale-package condition: NSX has already been removed from the host through NSX Manager, or the host has been removed from NSX Manager, but NSX VIBs remain on ESXi. One example is the dependency error covered by Broadcom KB 409544, where vsipfwlib remains dependent on nsx-proto2-libs.

This is not a shortcut for dismantling an active transport node. If NSX Manager still shows the host as configured, if workloads or VMkernel adapters still depend on NSX-backed networking, or if the supported removal command reports attached resources, resolve those dependencies before continuing. Do not bypass the command’s safety checks by deleting individual VIBs.

Step 1: Evacuate the Host and Enter Maintenance Mode

Before attempting either the NSX Manager removal or the stale-VIB cleanup:

  1. Evacuate powered-on workloads from the host.
  2. Put the host into maintenance mode.
  3. Confirm that the cluster and its storage can tolerate the host being unavailable.
  4. Keep console or out-of-band management access available in case normal host networking is interrupted.

Do not perform this cleanup on an in-service host.

Step 2: Remove or Unprepare the Host in NSX Manager

Use NSX Manager as the first removal method. Select the applicable Remove NSX or unprepare action for the host transport node. The exact navigation label varies by NSX release. Wait for NSX Manager to report the host as Not Configured before treating the remaining packages as stale.

For one currently documented reinstall scenario, Broadcom directs administrators to go to System > Fabric > Hosts, move the host out of the prepared cluster, and use Remove NSX if it does not transition to Not Configured. See KB 401684 and confirm the matching procedure for your installed NSX version.

Step 3: Confirm Which NSX VIBs Remain

Log in to the ESXi shell as an authorized administrator and list the relevant packages:

esxcli software vib list | grep -E 'nsx|vsipfwlib'

Record the output for troubleshooting. If the command returns no matching packages, there are no NSX VIBs for this procedure to remove. Reconcile the host’s state in NSX Manager instead of continuing blindly.

Step 4: Use the Supported NSX Removal Command

For the stale-VIB condition documented in KB 409544, run:

nsxcli -c del nsx

Allow the command to complete. If it fails, stop and address the reported dependency or attached-resource condition. Do not replace it with individual esxcli software vib remove commands. Broadcom’s KB 426464 explicitly says to correct the condition causing del nsx to fail rather than using the unsupported ESXCLI method.

Step 5: Reboot and Verify the Host

KB 409544 requires a reboot after the removal. Reboot the host while it remains in maintenance mode. After it has returned, log in and repeat the package check:

esxcli software vib list | grep -E 'nsx|vsipfwlib'

For the KB 409544 condition, the expected result is no matching NSX VIBs. Also verify that:

  • The management interface is reachable.
  • NSX Manager reports the host as Not Configured if it is meant to remain unprepared.
  • No stale NSX-backed distributed-switch resources remain associated with the host.

If you intend to prepare the host again, initiate that operation from NSX Manager. Wait for the transport node to report a healthy state, then validate management connectivity, workload networking, and tunnel status before exiting maintenance mode.

If ESXCLI Removal Was Already Attempted

If individual NSX VIBs were already removed and the host lost network connectivity, do not continue removing packages. Use console or out-of-band access and follow the recovery article that matches the symptom:

When the host’s current state does not match either documented scenario, collect diagnostics and open a Broadcom Support case rather than combining cleanup commands from unrelated KB articles.

Official References