In VMware NSX, a Virtual Private Cloud (VPC) object may become stuck in a pending delete or realized state within the NSX Manager UI. This occurs when transitioning between connectivity modes (e.g., from Distributed VLAN to Centralized connectivity).
Symptoms:
vmware-system-supervisor-services-vpc_<suffix>) remains visible in the UI despite deletion attempts.DELETE calls for associated logical switches return a 404 NOT_FOUND error, even though the records persist in the database.realized-entities output shows a RealizedLogicalRouterPort (service-interface) in a REALIZED state with a reference to a dangling logical switch.This issue is caused by a failure in the VPC realization cleanup workflow. During the transition between connectivity modes, the Policy-layer intent tree is purged, but the underlying system-owned Manager-layer (MP) objects—specifically the LogicalSwitch and its associated IndexPool VLAN allocation—are skipped. These "orphaned" MP objects remain in the Corfu database with systemOwned: true protection, rendering them unreachable via standard Policy APIs and protected against user-initiated MP deletion.
To resolve this issue, the stale records must be manually purged from the Corfu database tables.
If you believe you have encountered this issue, open a support case with Broadcom Support
Prerequisites:
Collect NSX Manager log bundle
Collect the following table dumps and extract the text files from the /image directory on any one of the NSX Manager nodes after running the below commands from root:
corfu_tool_runner.py -o showTable -n nsx -t LogicalSwitch > /image/LogicalSwitch.txt
corfu_tool_runner.py -o showTable -n nsx -t LogicalSwitchState > /image/LogicalSwitchState.txt