Troubleshooting NSX N-VDS to VDS migration

Products

VMware NSX

Issue/Introduction

When troubleshooting N-VDS to VDS migration, a specific set of data must be gathered at the time of the event. This article details what documentation is required and how to gather it prior to opening a support request with Broadcom.

Environment

VMware NSX

Resolution

The N-VDS has been deprecated since VMware NSX 4.0.0.1 (NSX N-VDS Host Switch support), prior to upgrading to VMware NSX 4.x, you must migrate the N-VDS to DVS.

The migration can be done in one of 3 ways:

Using API's
Using Cli
Using NSX-T Quick Start and vCenter update manager

Details on each method can be found in the VMware NSX-T administration guide under section Migrate Host Switch to vSphere Distributed Switch

Using the command line to migrate, available commands from NSX CLI Guide:

vds-migrate precheck #VDS migration precheck

vds-migrate show-topology #VDS show topology

vds-migrate apply-topology #VDS apply topology

vds-migrate esxi-cluster-id #ESXi Cluster Id

vds-migrate esxi-cluster-name #ESXi Cluster Name

vds-migrate tn-list #VDS migration tn list

vds-migrate delete-topology #VDS delete topology

vds-migrate disable-migrate #Disable NVDS to VDS migration

Using the command line:

Log in as admin user on one of the NSX-T managers.
Carry out a pre-check, to see if hosts are ready to migrate, using the command:
- vds-migrate precheck -
- If you receive no error, just the precheck ID, then the pre-check has passed.
- If you receive any error or issues in the pre-check, correct these and rerun the pre-check.
Once the pre-check is complete, receive the pre-check ID, next retrieve the suggested topology using the command:
- vds-migrate show-topology
The pre-check ID for the topology should match the returned pre-check ID in the previous step.
Then to apply the topology, create the DVS, run the following command:
- vds-migrate apply-topology
You can check in vCenter now that the DVS is created, no hosts are migrated from the N-VDS yet.
To begin the host migration, you do either per cluster or per host:
- Per cluster, run the following command:
  - vds-migrate esxi-cluster-name <cluster-name>
  - Substitute <cluster-name> with the name of the cluster you want to migrate, e.g.
  - vds-migrate esxi-cluster-name workload-cluster
- Per host, you can migrate individual hosts, create a file with the list of transport nodes to migrate in this operation and use the list in the command:
  - vds-migrate tn-list /opt/tnid
- Where /opt/tnid is the file containing the list of hosts/transport nodes to be migrated, you can select the list of transport UUID's from the results of the show-topology command.
- Note: You will need to login as root to create the file /opt/tnid with the list of hosts. You can edit this file and add remove hosts as they are complete and run the command again.
During the migration, the hosts will enter maintenance mode, you can set a delay timeout for the hosts on either of the above command using the option maintenance-timeout <value> in minutes, for example the following command sets a timeout of 15 minutes for the hosts list:
- vds-migrate tn-list /root/tnid maintenance-timeout 15
Any issues encountered, review the /var/log/nsx-cli/nsxcli.log and /var/log/proton/nsxapi.log on the NSX-T manager where the commands where executed.

Using API's:

Check the hosts are ready to migrate:
- Management Plane API:
  POST https://<nsx-mgr>/api/v1/nvds-urt/precheck
- Policy API:
  PUT /policy/api/v1/infra/nvds-urt/precheck
- Expected response, the precheck id, if you receive the id with no error, the precheck passed:
  { "precheck_id": "########-####-####-####-############" }
If you wish to retrieve the status of the pre-check, for example if it failed and you need to check again what the reason was, you can run the the following API call:
- Management Plane API
  GET https://<nsx-mgr>/api/v1/nvds-urt/status-summary/<precheck-id>
- Policy API:
  GET /policy/api/v1/infra/nvds-urt/status-summary/<precheck-id>
- Sample response:
  {
  "precheck_id": "########-####-####-####-############",
  "precheck_status": "PENDING_TOPOLOGY",
  "precheck_issue": [
  {
  "component": "Uplink profile",
  "objid": "nsxvswitch1",
  "warning": "Found inconsistent profiles: [########-####-####-####-############, ########-####-####-####-############]. Uplink profile mismatch. Mtu mismatch. ",
  "recommendation": "Keep profiles consistent among transport nodes in the same NVDS",
  "_protection": "NOT_PROTECTED"
  }
  ]
  }
- Resolve any pre-check errors, before proceeding.
To review the recommended topology, run the following API call:
- Management Plane API:
  GET https://<nsx-mgr>/api/v1/nvds-urt/topology/<precheck-id>
  Policy API:
  GET /policy/api/v1/infra/nvds-urt/topology/<precheck-id>
- Sample response:
  {
  "topology": [
  {
  "nvds_id": "########-####-####-####-############",
  "nvds_name": "nsxvswitch1",
  "compute_manager_topology": [
  {
  "compute_manager_id": "########-####-####-####-############",
  "dvswitch": [
  {
  "data_center_id": "datacenter-4",
  "vds_name": "VDS-nsxvswitch1-datacenter-4-0",
  "vmknic": [],
  "transport_node_id": [
  "########-####-####-####-############"
  ],
  "id": "########-####-####-####-############",
  "_protection": "NOT_PROTECTED"
  },
  {
  "data_center_id": "datacenter-4",
  "vds_name": "VDS-nsxvswitch1-datacenter-4-1",
  "vmknic": [],
  "transport_node_id": [
  "########-####-####-####-############"
  ],
  "id": "########-####-####-####-############",
  "_protection": "NOT_PROTECTED"
  },
  {
  "data_center_id": "datacenter-22",
  "vds_name": "VDS-nsxvswitch1-datacenter-22-2",
  "vmknic": [],
  "transport_node_id": [
  "########-####-####-####-############",
  "########-####-####-####-############"
  ],
  "id": "########-####-####-####-############",
  "_protection": "NOT_PROTECTED"
  }
  ]
  }
  ],
  "id": "########-####-####-####-############",
  "_protection": "NOT_PROTECTED"
  }
  ]
  }
Once happy pre-checks are resolved and topology is good, you can apply the topology, this will create the VDS in vCenter, but not migrate any hosts yet:
- Management Plane API:
  POST https://<nsx-mgr>/api/v1/nvds-urt/topology?action=apply
- Policy API:
  PUT /policy/api/v1/infra/nvds-urt/topology?action=apply
- Note: The suggested VDS name can be edited in the API call, take the results of the suggested topology and change the name before applying, but you can only add a new name, not one of an existing VDS.
You can check the status of the migration using the pre-check ID:
GET https://<nsx-mgr>/api/v1/nvds-urt/status-summary/<precheck-id>
When the topology is ready for migration, its status changes from APPLYING_TOPOLOGY to READY and each host will have a status of UPGRADE_READY.
- Once this is ready, place ESXi host in maintenance mode in vCenter and begin the migration:
  POST https://<nsx-mgr>/api/v1/transport-nodes/<tn-id>?action=migrate_to_vds
- Where tn-id is the ID of the host you wish to migrate, this can be found in the GET topology pre-check results previously.
- Migration of hosts are done serially, if you wish to do hosts in parallel, you can run the API again with another host, after placing it in maintenance mode in vCenter.
You can check the status of the migration using the API:
GET https://<nsx-mgr>/api/v1/nvds-urt/status-summary/<precheck-id>
Sample response:
{
"precheck_id": "########-####-####-####-############",
"precheck_status": "READY",
"migration_state": [
{
"host": "########-####-####-####-############",
"overall_state": "UPGRADE_READY"
},
{
"host": "########-####-####-####-############",
"overall_state": "UPGRADE_READY"
},
{
"host": "########-####-####-####-############",
"overall_state": "SUCCESS"
}
]
}
When a host has been migrated, the overall_state changes to SUCCESS
If there is some issue and the migration fails, the overall_state changes to FAILED, with a reason it failed, once the issue is resolved, you can run the migrate_to_vds API again for the host.