Troubleshooting missing NSX-T segments in vCenter networking inventory

Products

VMware vCenter Server VMware NSX

Issue/Introduction

After creating or modifying segments in NSX-T Manager, the segments do not appear in the vCenter Server networking inventory despite being in a "Realized" state.

Segments are confirmed as "Success" and "Realized" within the NSX-T Manager and CLI, but remain invisible in the vSphere Client.
The absence of these segments in vCenter prevents administrators from attaching Virtual Machines to the required network backing.
The problem stems from a disconnect between the Management Planes (NSX-T and vCenter), where the vCenter database fails to index new "Opaque Network" objects.

Environment

VMware vCenter Server

VMware NSX

Cause

The issue is caused by a communication break between vCenter and NSX-T, triggered by a mismatch in how the Distributed Switch (DVS) is identified.

Identity Disruption: When a DVS is renamed in vCenter, its internal "address" (path and pointers) changes. This breaks the active link or "handshake" with NSX-T, which is still looking for the old name.
Stale Caching: vCenter’s management service (vpxd) saves a "snapshot" (cache) of network objects to improve performance. Even if you rename the switch back to its original name, vCenter may continue to use an old, stuck version of this snapshot.
Sync Failure: Because of this stale cache, vCenter thinks the "current" switch is a different object than the one NSX is trying to update. As a result, it fails to index or display any new segments in the user interface.

Resolution

To resolve the synchronization discrepancy and force vCenter to rebuild its network object mapping, follow these steps to validate the environment and refresh the management services.

Step 1: Validate NSX-T to vCenter Alignment

Before performing a service restart, confirm that the fundamental communication and configuration paths are intact:

Check Compute Manager Health: In the NSX Manager, go to System > Fabric > Compute Managers. Confirm that the vCenter registration status is Success and the connection status is Up.
Verify Segment Association: Navigate to Networking > Segments. Ensure the missing segment is correctly assigned to the intended Transport Zone and that the zone is mapped to the correct VDS.
Perform a Graceful Re-authentication: (Recommended) Before a full restart, go to the Compute Manager settings, click Edit on the vCenter entry, and click Save. This can sometimes clear minor cache synchronization issues without a service interruption.

Step 2: Execute a Full Service Resynchronization

If the configuration is valid but the vSphere Client remains out of sync, a restart of the core services is necessary to flush the stale vpxd metadata cache and force a new inventory handshake.

Access the VCSA: Log in to the vCenter Server Appliance (VCSA) via SSH using root credentials.
Enable Shell: At the command prompt, type shell to enter the BASH interface.
Restart All Services: Execute the following commands to stop and restart the vCenter management stack. This forces a complete reload of the database and triggers a full inventory sync with NSX-T:
```
service-control --stop --all
service-control --start --all
```
Confirm Inventory Recovery: After the services have successfully initialized (approximately 5–10 minutes), log in to the vSphere Client. Navigate to Inventory > Networking and verify that the NSX-T segments are now correctly populated under the Distributed Switch.

Additional Information

Log Verification: To confirm the sync is in progress, you can monitor /var/log/vmware/vpxd/vpxd.log for entries containing OpaqueNetwork or NSX.
Best Practice: Avoid renaming the DVS in vCenter once it has been prepared for NSX-T. If a name change is necessary, perform it during a maintenance window as it will likely require the service restart outlined above to maintain inventory consistency.