In an NSX Federation environment, you observe the following symptoms:
VMware NSX
This issue is caused by a site configuration inconsistency on the Local Manager. Specifically, the LM may have a view where it identifies two Global Managers as "Active." When the legitimate Active GM sends a synchronization handshake, the LM rejects it because it does not match the first "Active" site in its internal list. This prevents the LM from sending the necessary delete notifications back to the GM to purge the DeletesPending table.
To resolve this issue, you must correct the site configuration on the Local Manager and trigger a manual synchronization.
Verify the conflict:
Log in to the problematic Local Manager (LM) via SSH as root and run the following command to check the site configuration:curl -X GET -ik http://localhost:7999/api/v1/sites
Confirm if the output incorrectly lists more than one site with "active_gm": "ACTIVE".
Re-onboard the LM site from the Active Global Manager using the following API (replace placeholders with your environment details):curl -X POST -ik http://localhost:7999/api/v1/sites?action=onboard_site -H "Content-Type: application/json" -d '{"address": "####", "username": "####", "password": "####", "thumbprint": "####", "site_name": "####", "standby_gm":false}'
Trigger notification synchronization:
Once the site configuration is in sync (showing one Active and one Standby GM), log in to a manager node on the LM and trigger a full notification sync to flush the stale entries:POST https://####/policy/api/v1/infra/full-sync-action?action=request_notifications_full_sync
Verification:
Refresh the Global Manager UI. The greyed-out objects should no longer be visible.
VMware NSX