soglesby
Contributor
Contributor

Transport zones associated with nonexistent logical switches

Running NSX 6.1.2.

Somehow (unknown root cause), VXLAN configuration got into an error state and I had to reconfigure it. To do that, I had to remove all logical switches from the single cluster and pretty much clean everything out to clear all the dependencies. (Test environment, so not a disaster.)

But now I have two transport zones that cannot be deleted because NSX reports they are still associated to nonexistent logical switches.

The UI is consistent with API results (below): summary view for the TZ shows 1 or 2 logical switches, but the detail (related objects view) list is empty for the TZ.

API calls:

Summary for transport zone (vdnscope): 2 logical switches (virtual wires):

GET https://${NSX_MANAGER_URL}/api/2.0/vdn/scopes/vdnscope-4

<vdnScope>

  <objectId>vdnscope-4</objectId>

  <objectTypeName>VdnScope</objectTypeName>

  <vsmUuid>420D40E8-2DEF-E4A3-26A5-365D194C67EB</vsmUuid>

  <revision>1</revision>

  <type>

  <typeName>VdnScope</typeName>

  </type>

  <name>danger zone</name>

  <description>test transport zone</description>

  <clientHandle />

  <extendedAttributes />

  <id>vdnscope-4</id>

  <clusters />

  <virtualWireCount>2</virtualWireCount>

  <controlPlaneMode>HYBRID_MODE</controlPlaneMode>

</vdnScope>

List of associated virtual wires: empty list:

GET https://${NSX_MANAGER_URL}/api/2.0/vdn/scopes/vdnscope-4/virtualwires

<virtualWires>

  <dataPage>

  <pagingInfo>

  <pageSize>20</pageSize>

  <startIndex>0</startIndex>

  <totalCount>0</totalCount>

  <sortOrderAscending>true</sortOrderAscending>

  </pagingInfo>

  </dataPage>

</virtualWires>

But delete is blocked:

DELETE https://${NSX_MANAGER_URL}/api/2.0/vdn/scopes/vdnscope-4

<error>

  <details>Transport zone vdnscope-4 is in use. All dependent logical switches must be removed prior to deletion.</details>

  <errorCode>812</errorCode>

  <moduleName>core-services</moduleName>

</error>

I'm at a loss of how to clean this up. Would prefer not to have to reinstall everything. Has this happened to anyone else?

5 Replies
MR-Z
VMware Employee
VMware Employee

Did you resolve your issue?

I ran into similar issue recently and am struggling to figure out how to get out of this.

0 Kudos
soglesby
Contributor
Contributor

Sorry, I never solved it. We eventually replaced it with a 6.1.3 install (for test coverage), so it was basically the "nuke and start over" workaround that I wanted to avoid.

0 Kudos
MR-Z
VMware Employee
VMware Employee

Thanks for confirming. I was able to resolve my issue today. Turned out that I did have some logical switches in "discarded state" which the UI does not list. Getting the status of the virtual wires requires to work with support, but you can also query them brute-force like this:

GET https://nsx-manager-IP/api/2.0/vdn/virtualwires/virtualwire-1

GET https://nsx-manager-IP/api/2.0/vdn/virtualwires/virtualwire-2

GET https://nsx-manager-IP/api/2.0/vdn/virtualwires/virtualwire-3

etc.

If the virtualwire does not exist, you would get "virtualwire-1' could not be found.

Say when you query 'virtualwire-3' and it returns a valid virtual wire, you can then delete it:

DELETE https://nsx-manager-ip/api/2.0/vdn/virtualwires/virtualwire-3

soglesby
Contributor
Contributor

Cool. Did you by chance do a GET /api/2.0/vdn/virtualwires (list all virtual wires) before your fix? I'm wondering if the logical switches in deleted state (not shown in UI) still showed up in that response.

0 Kudos
MR-Z
VMware Employee
VMware Employee

I did. I basically go this back (same as if you query the virtualwire from within the vdnscope context)...

<?xml version="1.0" encoding="UTF-8"?>

<virtualWires>

    <dataPage>

        <pagingInfo>

            <pageSize>20</pageSize>

            <startIndex>0</startIndex>

            <totalCount>0</totalCount>

            <sortOrderAscending>true</sortOrderAscending>

        </pagingInfo>

    </dataPage>

</virtualWires>

0 Kudos