Transport Zone Validation Error when trying to add VxRail host to new cluster on a new compute manager (vCenter with same VDS name)
search cancel

Transport Zone Validation Error when trying to add VxRail host to new cluster on a new compute manager (vCenter with same VDS name)

book

Article ID: 393206

calendar_today

Updated On:

Products

VMware NSX

Issue/Introduction

A reformatted VxRail host is added into a new cluster (using the same VDS name) on a new compute manager (vCenter with same VDS name), and the following error is received:

Validation Errors 

9560:Transport Zone

TransportZone/<UUID> cannot be relocated from HostSwitch <current host switch name> to HostSwitch <host switch name in Transport Node Profile> in a single transaction. Delete Host Switch from current Transport Zone to add later to another Transport Zone."

 

 

 

Environment

VMware NSX 4.x
VMware NSX-T Data Center 3.x

Cause

When an ESXi host is removed directly from vCenter without first removing NSX, entries for that host can remain in the NSX database and NSX does not automatically move a Transport Zone already in use from one host switch to another.

The correct procedure to remove NSX from a single host:

 

Resolution

Confirm the UUID of vDS on both vCenters:

  1. On the vSphere client Inventory, change to Network view.

  2. Select the vDS and in the url bar the moid is identified. In this example, Test-Switch has a moid of dvs-204####.




  3. Open a new browser tab and use the url https://VCENTER_FQDN_or_IP/mob/?moid=<value identified above i.e. dvs-204####>

 

     The UUID of the vDS is 50 1d 74 40 ## ## ## b1-bd ## ## ## 41 fc 21 6f

Workaround: 

Option 1:

If the existing host switch name is acceptable, reconfigure the applied Transport Node Profile to use the current host switch name seen in vCenter.

To update the host switch name configured in the Transport Node Profile, navigate to "System > Fabric > Profiles > Transport Node Profiles > Select profile > Edit"

Option 2:

A) In some cases, you will still see the impacted host in the NSX UI:

  1. In the NSX UI, check if you can find the impacted Host on the following pages:

     System > Fabric > Hosts > Cluster

     System > Fabric > Hosts > Other hosts

     System > Fabric > Hosts > Standalone

  2. If the ESXi host is present here, select it and click Delete NSX and select Force Delete.

  3. Once the force delete is complete, the ESXi host can now be re-added to vCenter.

  4. If the Host is not present, please proceed to Option 2. If you have already completed Option 2 and retrying Option 1 after reindexing and the issue is still not resolved, please proceed to Option 3.

B) Sometimes, the host may not appear in the NSX UI due to search indexing failures:

  1. On all three NSX manager nodes, log in as the admin user and run the following two commands:

    start search resync policy

    start search resync manager

  2. After you run the above commands, please allow some time for the reindexing to complete. This depends on the size of the environment, but please allow at least 10 minutes.
    Note: During the reindexing period, you may notice the NSX UI displays an error related to the indexing and indicates to try again later; this is expected due to the indexing occurring.

  3. Once the reindexing is complete, after at least 10 minutes, go back to Option 1 and follow the steps there again.

C) If you have completed A & B and the host still does not appear on the NSX UI, to allow removal, the following API steps can be used to remove the transport node.

  1. Run the following API call:
    GET https://<NSX Mgr IP>/api/v1/transport-nodes/<UUID>/state command. 

    Note: Replace <UUID> with the Transport Node UUID, as reported in the error message (see Issue/Introduction section).
    Replace <NSX Mgr IP> with the IP address or FQDN of an NSX manager node.

  2. If the state value in the API response is not Object Not found then proceed to step 3.
    Note: The state value should be object not found when the host is successfully removed.

  3. For NSX-T 3.2.x and 4.x, run the following API call:
    DELETE     https://<NSX Mgr IP>/api/v1/transport-nodes/<UUID>?force=true&unprepare_host=false

    Note: Replace <UUID> with the Transport Node UUID, as reported in the error message (see Issue/Introduction section).
    Replace <NSX Mgr IP> with the IP address or FQDN of an NSX manager node.
    If using curl to run this API, the full url must be in double quotes.

  4. Wait five minutes, then run the GET transport node state command again, as seen in Step 1 periodically until  "Object Not found" is returned.

  5. Once GET API returns "Object Not found", move the host back into the original cluster to prepare it for NSX. If a Transport Node Profile is applied, host preparation should start automatically. Otherwise, proceed and prepare the transport node as before.

If none of the options have resolved the issue, please collect the information outlined in the Additional Information section below, open a technical support case with Broadcom Support for further investigation, and refer to this KB article.

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

Additional Information

If you are contacting Broadcom support about this issue, in order to aid a timely response and resolution, please provide the following:

  • NSX version.
  • Was the issue encountered during an upgrade or install.
  • Where all workaround options completed and if not, which options were not completed and reason why they were not completed or what issue prevented completion of them.
  • NSX Manager log bundles.
  • ESXi host log bundles for hosts that are failing to configure as transport nodes.
  • Text of any error messages seen in NSX GUI or command lines pertinent to the investigation and screenshot.

Handling Log Bundles for offline review with Broadcom support:

Related Installation documentation:

Powered by Wolken Software