This is the corrected follow-up to my older article about simplifying NSX Edge removal in VCF. The most important correction is that the Edge Cluster Deployment Removal Tool does not preserve everything attached to an Edge cluster. Broadcom requires added dependencies to be removed or disconnected before the cleaner runs.

The procedure below is based on Broadcom KB 316110, reviewed on August 25, 2026. Always reopen the KB before a change because the attachment, checksum, prerequisites, and supported releases can change.

Destructive operation: The cleaner removes the selected deployment’s NSX gateways, Edge cluster and node VMs, network objects, associated vCenter objects, and SDDC Manager inventory records. A successful dry run is necessary, but it is not a rollback mechanism and does not replace dependency analysis or backups.

Confirm That the Deployment Is Supported

Use this cleaner only for an NSX Edge cluster deployment created through one of these SDDC Manager workflows:

  • An Application Virtual Network (AVN) bring-up workflow.
  • The SDDC Manager Edge Cluster Creation workflow, including the corresponding UI workflow.

KB 316110 describes the cleaner as intended for freshly deployed Edge clusters. Stop and open a Broadcom Support case when the deployment’s origin or current inventory association is unclear.

The current cleaner also exposes a separate --db-removal-only mode for a specific VCF 9.x imported-Edge inventory scenario. That mode does not perform the deployment cleanup described here and is outside this article’s scope; use it only under the current KB instructions or Broadcom Support guidance.

Do not use this workflow when:

  • The Edge cluster is being used by Workload Control Plane (WCP), vSphere with Tanzu, or dependent Kubernetes services.
  • The Edge cluster was created outside the supported SDDC Manager workflows.
  • Edge VMs, gateways, or inventory records were already deleted manually and SDDC Manager no longer matches NSX or vCenter.
  • Fabric or logical objects created by SDDC Manager were renamed and their original names are unknown.
  • The requested action is to shrink, migrate, or repair an active Edge cluster rather than remove the deployment.

Manual deletion can leave SDDC Manager inventory out of sync with NSX and vCenter. Broadcom directs administrators who reach that state to open a support case rather than continue deleting objects; see KB 437372.

Remove Dependencies Before Running the Cleaner

Inventory everything using the Edge cluster and migrate or remove it before continuing. This includes, as applicable:

  • Added Tier-0 or Tier-1 gateway configuration.
  • Segments linked to a Tier-1 gateway.
  • Interfaces, services, static routes, NAT, VPN, load-balancing, DHCP, or other configuration attached above the SDDC Manager-created deployment.
  • External Connections and Transit Gateway dependencies in applicable VCF 9.x deployments.
  • WCP and related components, which must be removed through the supported vCenter workflow before the Edge cluster can be reconsidered for cleanup.

Revert renamed fabric or logical entities to the names assigned by the SDDC Manager deployment workflow. The cleaner has only limited ability to disconnect linked segments; do not rely on the dry run to discover or safely migrate every application dependency.

Obtain approval from the network and application owners after confirming that removing the identified gateways and Edge nodes will not interrupt a service that should remain available.

Prepare Backups and Recovery Access

Before running a destructive cleanup:

  1. Verify a current, successful NSX file-based backup and confirm access to its passphrase and remote backup files.
  2. Follow the current VCF backup guidance for SDDC Manager. Take an SDDC Manager VM snapshot only when the Broadcom procedure or Support guidance for the specific scenario instructs you to do so, and remove it promptly after successful validation.
  3. Do not snapshot NSX Manager, Global Manager, or Edge appliances. Broadcom documents that VM snapshots of NSX appliances are unsupported and can cause database corruption or cluster instability; use the supported NSX file-based backup instead. See KB 433822.
  4. Schedule a maintenance window and keep console access to SDDC Manager, NSX, and vCenter available.

Download and Verify the Current Tool

Open KB 316110 and download its current Edge cleaner attachment. Do not reuse an older tarball or a bookmarked attachment URL.

The KB publishes the filename and hashes for its current attachment and warns that the hashes change when the file changes. Copy the tarball to /home/vcf on the SDDC Manager appliance, not /tmp, then calculate its SHA-256 hash:

cd /home/vcf
sha256sum 'edge_cluster_cleaner_<version>.tar.gz'

Replace <version> with the exact version in the downloaded filename. Compare the entire result with the current SHA-256 value shown in KB 316110. Stop if the filename or hash does not match.

Extract the verified attachment and inspect the bundled help:

tar -xzvf 'edge_cluster_cleaner_<version>.tar.gz'
cd cleanup
./remove_edge_cluster.sh --help

Use the flags reported by the downloaded tool. If its syntax differs from the KB or this article, stop and reconcile the version before continuing.

Run a Dry Run First

Use the exact Edge cluster name and, when supplied, the exact workload-domain name. Use a vCenter SSO administrator for the workload domain. Do not place its password on the command line; when neither a password flag nor password environment variable is supplied, the tool prompts for it without storing it in shell history.

./remove_edge_cluster.sh \
  --cluster '<EDGE_CLUSTER_NAME>' \
  --workload '<WORKLOAD_DOMAIN_NAME>' \
  --user '<SSO_ADMIN_USER>' \
  --dryrun \
  --verbose

The --workload argument is optional in the documented tool, but specifying the intended domain makes the target explicit. Review the dry-run output and generated log from beginning to end. Confirm that:

  • The tool authenticated to the intended environment.
  • The selected Edge cluster and workload domain are correct.
  • Every object proposed for deletion belongs to the intended deployment.
  • No unexpected dependency, renamed object, validation failure, or inventory mismatch appears.

If any check fails, do not add force or warning-suppression flags. Correct the prerequisite or open a Broadcom Support case, then repeat the dry run.

Run the Live Cleanup

After the dry run succeeds and the change is approved, run the same command without --dryrun:

./remove_edge_cluster.sh \
  --cluster '<EDGE_CLUSTER_NAME>' \
  --workload '<WORKLOAD_DOMAIN_NAME>' \
  --user '<SSO_ADMIN_USER>' \
  --verbose

Read the warning and confirm the target interactively. Do not use --skip-warning merely to make the example noninteractive. Keep the terminal connected until the cleaner finishes and retain its log with the change record.

KB 316110 notes that a transient timeout can occasionally stop cleanup partway through. In that documented timeout condition, inspect the log and rerun the same cleaner invocation. If the Edge cluster was dissolved but its Edge node VMs remain, follow the KB’s specific direction to remove those residual Edge Transport Node VMs through the NSX UI. Do not improvise manual deletion for other partial states.

Validate All Three Inventories

After the cleaner reports success, verify the result in:

  1. SDDC Manager: the Edge deployment and its workload-domain inventory association are removed.
  2. NSX Manager: the intended gateways, Edge cluster, Edge nodes, uplink segments, and SDDC Manager-created transport-zone objects are gone, with no new alarms or stale dependencies.
  3. vCenter Server: the intended Edge node VMs, port groups, and deployment resource pool are gone, while unrelated infrastructure remains present.

Also test the management and workload paths that were intentionally migrated away from the removed Edge cluster. If the three inventories disagree, stop. Do not manually delete more objects to make the screens match; collect the cleaner log and support bundles and open a Broadcom Support case.

What the Cleaner Normally Removes

Depending on whether the deployment came from AVN bring-up or direct SDDC Manager Edge creation, KB 316110 says the cleaner normally removes some or all of the following:

  • The deployment’s Tier-0 and Tier-1 gateways.
  • The Edge cluster and Edge node VMs.
  • Edge uplink segments and deployment-created VLAN transport zones.
  • Deployment-created vCenter port groups and resource pool.
  • The corresponding SDDC Manager inventory records.

That list is the reason dependency removal and a reviewed dry run come first. The cleaner is a deployment-removal tool, not an application-migration or dependency-preservation tool.

Official References