How to remove ghost or stale dvportgroup from vCenter inventory
search cancel

How to remove ghost or stale dvportgroup from vCenter inventory

book

Article ID: 447426

calendar_today

Updated On:

Products

VMware NSX VMware vCenter Server

Issue/Introduction

  • Duplicate portgroups are visible in vCenter Server for NSX logical segments.
  • NSX manager does not list these duplicates.
  • We can see the duplicates when searched on the vSphere Client but not on NSX manager.
  • Both the portgroups have same segment ID but are on different Distributed Switches with different MOID
  • Removing the duplicate dvportgroup with MOID from MOB as instructed in KB  369037  fails and the dvportgroup still remains in vCenter server inventory.
  • Removing the duplicate dvportgroup from VCDB will recreate the deleted dvportgroup with new MOID :-

journalctl_-b--0.txt
Jun 08 10:41:52 example.com vpxd[3481480]: Event [38881769] [1-1] [2026-06-08T10:41:52.745923Z] [vim.event.DVPortgroupCreatedEvent] [info] [com.vmware.nsx.management.nsxt] [<Datacenter name>] [38881769] [dvPort group <dvportgroup name> in <Datacenter name> was added to switch <VDS name>.]

(This command displays the vpxd service logs, which contain detailed information about various vCenter operations)

  • (#vdsIdPortGroupStateMap = 2).This clarifies duplicate portgroup entry exist in NSX side ( corfuDB) which is pushing the update to add the dvportgroup in vcenter inventory.

 less /var/log/syslog | grep -i "dvportgroup name"                                                                                                           
2026-06-08T10:41:31.230Z <server name>  NSX 5303 SWITCHING [nsx@6876 comp="nsx-manager" level="INFO" subcomp="manager"] Updated LogicalSwitchState: LogicalSwitchState [id =LogicalSwitchState/####-###-#######-#####, revision = 196, logicalSwitchName = <dvportgroup name>, stateStatus = SUCCESS, switchType = DEFAULT, logicalSwitchRevison = 0, portGroupStateRevision = 0, #vdsIdPortGroupStateMap = 2, #networkIdFolderStateMap = 0, nextRealizationTime = 0]


less /var/log/proton/nsxapi.log | grep -i "dvportgroup name"
2026-06-08T10:41:31.230Z  INFO l2VcFullSyncScheduler1 LogicalSwitchStateServiceImpl 5303 SWITCHING [nsx@6876 comp="nsx-manager" level="INFO" subcomp="manager"] Updated LogicalSwitchState: LogicalSwitchState [id =LogicalSwitchState/####-###-#######-#####, revision = 196, logicalSwitchName =<dvportgroup name>, stateStatus = SUCCESS, switchType = DEFAULT, logicalSwitchRevison = 0, portGroupStateRevision = 0, #vdsIdPortGroupStateMap = 2, #networkIdFolderStateMap = 0, nextRealizationTime = 0]

Note: The preceding log excerpts are only examples. Date, time, and environmental variables may vary depending on your environment.

Environment

VMware NSX

VMware vCenter Server

Cause

The NSX LogicalSwitchState for the affected segments has two VDS entries in vdsIdPortGroupStateMap (two distinct VDS UUIDs), one of which carries a ghost portgroup key.

the state for that entry is PORT_GROUP_STATE_ENUM_SUCCESS, the nsx-switching portgroup reconciliation loop treats the DVPG as "should exist" and calls vds.addNsxPortgroups() to re-create it whenever it is manually deleted from VCDB, producing the duplicate.

Resolution

This is a condition that may occur in a VMware NSX environment.

Workaround :

Confirm if there are any stale entries that have failed to delete listed under the vdsIdPortGroupStateMap value: 

ssh as root to one of the NSX Managers and run the following :

Step 1: Collect LSS table dump from corfuDB

/opt/vmware/bin/corfu_tool_runner.py -n nsx -t LogicalSwitchState -o showTable > /tmp/LSS_table_dump.txt

Step 2 : Using LSS_table_dump to find the entries with  "vdsIdPortGroupStateMap" .(Refer log snippet above where "vdsIdPortGroupStateMap=2" )

Payload:
{
  "managedResource": {
    "displayName": "####-####-####-#####"
  },
  "ccpRealizedRevison": -1,
  "opaqueNetworkOnComputeManagerStateRevision": -1,
  "logicalSwitchDisplayName":"dvportgroup name"
  "transportZoneId": {
    "uuid": {
      "left": "123456789000000000000",
      "right": "123456789000000000000"
    }
  },
  "stateStatus": "CONFIG_STATUS_SUCCESS",
  "lastUpdated": "1780942977722",
  "switchType": "LOGICAL_SWITCH_TYPE_DEFAULT",


  "vdsIdPortGroupStateMap": {
    "50 34 9a ef 83 79 ## ## ## ## ## ## ## ##": {       ==========> Here
      "portGroup": {
        "cmId": "####-####-####-#####-###########",
        "portGroupKey": "dvportgroup-####5"
      },
      "state": "PORT_GROUP_STATE_ENUM_SUCCESS"
    },
    "50 34 23 56 db 5e ## ## ## ## ## ## ## ## ## ##": {    ===========> Here
      "portGroup": {
        "cmId": "####-####-####-#####-###########",
        "portGroupKey": "dvportgroup-####6"
      },
      "state": "PORT_GROUP_STATE_ENUM_SUCCESS"
    }
  }
}

Step 3 : Finding the duplicate portgroup from logs using the dvportgroupkey value.

┌less /var/log/vmware/vpxd
└─$ less vpxd* | grep -i "dvportgroup-####8"       =================> Here is GHOST dvportgroup
 
less /var/log/vmware/vpxd
└─$ less vpxd* | grep -i "dvportgroup-####0"
2026-06-08T07:01:44.699Z info vpxd[2167501] [Originator@6876 sub=vpxLro opID=q-60###90:h5ui-getProperties:urn:vmomi:DistributedVirtualPortgroup:dvportgroup-####0:####-####-####-#####-###########:1614615693:01-98] [VpxLRO] -- BEGIN lro-49107319 -- ResourceModel -- vim.dp.ResourceModel.queryBatch -- ####-####-####-#####-###########(#####-####-####-#####-###########)
 
Step 4 : This requires clean up of stale LSS :-
  • Step 1: Clean up the stale VDS from the NSX Corfu database.
  • Step 2: Remove the unused Port Groups (PGs) from the stale VDS in vCenter.

If you believe you have encountered this issue, open a support case with Broadcom Support and refer to this KB article.

For more information, see Creating and managing Broadcom support cases.