Migrate Host Switch to vSphere Distributed Switch

When using N-VDS as the host switch, NSX-T is represented as an opaque network in vCenter Server. N-VDS owns one or more of the physical interfaces (pNICs) on the transport node, and port configuration is performed from NSX-T Data Center. You can migrate your host switch to vSphere Distributed Switch (VDS) 7.0 for optimal pNIC usage, and manage the networking for NSX-T hosts from vCenter Server. When running NSX-T on a VDS switch, a segment is represented as an NSX Distributed Virtual Port Groups. Any changes to the segments on the NSX-T network are synchronized in vCenter Server. Note that in NSX-T Data Center 3.1, N-VDS to vSphere Distributed Switch migration is not supported for an N-VDS-based Collapsed Cluster environment. It is supported in NSX-T Data Center 3.1.1 without named teaming.

Starting with NSX-T Data Center 3.1.1, you can scale up migration by parallelly migrating hosts that are in maintenance mode through vSphere Lifecycle Manager or manually through APIs. By default, 64 hosts per cluster with a thread pool size of 22 per manager in a cluster can be migrated in parallel mode. Ensure that the batch size for parallel remediation is restricted to 4 nodes. For migration through vSphere Lifecycle Manager, "In Queue" status is shown for any host waiting for an available thread. For migration through API, any request over 64 active migration is rejected.

The parallel remediation feature requires vCenter Server 7.0 Update 2 or later. This feature is not supported for NSX-T Data Center 3.1 and should not be enabled for clusters under migration.

VDS to CVDS migration is triggered only for ESX upgrades that cross the 7.0.2 (X.Y.Z-U.P) release. Migration will not be triggered for any "U.P" (update-patch) upgrades. ESX version is specified as X.Y.Z-U.P where,

X = Major
Y = Minor
Z = Maintenance
U = Update
P = Patch

Note: The N-VDS to VDS migration tool is unavailable in NSX-T Data Center 3.2.0. If you want to migrate your workloads from N-VDS to VDS in this release, you will have to do so manually.

Starting with 3.2.1, a precheck run will not fail in case of incompatible configurations between transport nodes within the same NSX-T Data Center. For incompatible configurations of UplinkProfile, LLDPProfile, and NIOCProfile, precheck will generate configuration issues. You can check the incompatible configurations and determine whether you want to apply topology or align configurations between transport nodes and run precheck again.

Precheck will also create VDSs for each combination of different configuration. Recommended topologies will include all combinations of different configuration of transport nodes within the same NSX-T Data Center (or the same cluster in case of VCF). A specific VDS will be generated for transport nodes with equivalent UplinkProfile, LLDPProfile, and NIOCProfile.

Prerequisites

The following requirements must be met to migrate to a VDS 7.0 host switch:

vCenter Server 7.0 or later
ESXi 7.0 or later
NSX-T is no longer represented as an opaque network after migration. You may need to update your scripts to manage the migrated representation of the NSX-T hosts.

Procedure

Migrate your host switch using API calls or run the commands for migration from the CLI. You can also initiate migration from the NSX Manager user interface.

Note: Do not make any configuration changes to NSX-T Data Center until all your host switches have been successfully migrated.

Make the following API calls to perform the migration:

To verify that the hosts are ready for migration, make the following API call and run a precheck.

POST https://<nsx-mgr>/api/v1/nvds-urt/precheck

Policy API:

PUT /policy/api/v1/infra/nvds-urt/precheck

Example response:

{ "precheck_id": "166959af-7f4b-4d49-b294-907000eef889" }

Address any configuration inconsistencies and run the precheck again. Runing precheck after addressing configuration inconsistencies will not show inconsistent configurations again in the response.

Verify the status of the precheck. Inconsistent profiles will be shown as warning instead of error in the response.

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>

Example reponse:

{
    "precheck_id": "165a592d-a94f-4614-978c-9ca003cda278",
    "precheck_status": "PENDING_TOPOLOGY",
    "precheck_issue": [
        {
            "component": "Uplink profile",
            "objid": "nsxvswitch1",
            "warning": "Found inconsistent profiles: [b63afe90-ce04-46e4-a238-d7b63deada36, 0520a955-06cd-4498-883a-d534e8d7724c]. Uplink profile mismatch. Mtu mismatch. ",
            "recommendation": "Keep profiles consistent among transport nodes in the same NVDS",
            "_protection": "NOT_PROTECTED"
        }
    ]
}

For stateless hosts, nominate one of the hosts as the source host and initiate the migration.

To retrieve the recommended topology, make the following API call:

GET https://<nsx-mgr>/api/v1/nvds-urt/topology/<precheck-id>

Policy API:

GET /policy/api/v1/infra/nvds-urt/topology/<precheck-id>

Example response:

{
    "topology": [
        {
            "nvds_id": "e70a0fc2-7ec3-483e-9036-4eed170f0ecf",
            "nvds_name": "nsxvswitch1",
            "compute_manager_topology": [
                {
                    "compute_manager_id": "13127ee9-ea71-4c66-810e-c604d4f67fc4",
                    "dvswitch": [
                        {
                            "data_center_id": "datacenter-4",
                            "vds_name": "CVDS-nsxvswitch1-datacenter-4-0",
                            "vmknic": [],
                            "transport_node_id": [
                                "7af27ad7-4e45-4b36-95a2-d73413aea181"
                            ],
                            "id": "190125b2-d469-4bea-915b-6ffeb9e7b542",
                            "_protection": "NOT_PROTECTED"
                        },
                        {
                            "data_center_id": "datacenter-4",
                            "vds_name": "CVDS-nsxvswitch1-datacenter-4-1",
                            "vmknic": [],
                            "transport_node_id": [
                                "dca9568e-9587-4572-9001-c637960dbdae"
                            ],
                            "id": "9f039516-5318-4e14-8fd4-769d54560bcb",
                            "_protection": "NOT_PROTECTED"
                        },
                        {
                            "data_center_id": "datacenter-22",
                            "vds_name": "CVDS-nsxvswitch1-datacenter-22-2",
                            "vmknic": [],
                            "transport_node_id": [
                                "ebe67bdf-bb9c-4b92-8c81-cdb6ec2d8559",
                                "32058d07-dbba-4042-92f7-69ece1cc9680"
                            ],
                            "id": "9a389bf0-af53-4ace-b7d3-29b534fbab58",
                            "_protection": "NOT_PROTECTED"
                        }
                    ]
                }
            ],
            "id": "62f2fe60-1138-454d-99f2-8319255d8119",
            "_protection": "NOT_PROTECTED"
        }
    ]
}

Make the following API call to create a VDS with the recommended topology:

POST https://<nsx-mgr>/api/v1/nvds-urt/topology?action=apply

Policy API:

PUT /policy/api/v1/infra/nvds-urt/topology?action=apply

Note that you can only replace an N-VDS with a new VDS and cannot use an existing VDS.

Example input:

{
  "topology": [
    {
      "nvds_id": "c8ff4053-502a-4636-8a38-4413c2a2d52f",
      "nvds_name": "nsxvswitch",
      "compute_manager_topology": [
        {
          "compute_manager_id": "fa1421d9-54a7-418e-9e18-7d0ff0d2f771",
          "dvswitch": [
            {
              "data_center_id": "datacenter-3",
              "vds_name": "test-dvs",
              "transport_node_id": [
                "65592db5-adad-47a7-8502-1ab548c63c6d",
                "e57234ee-1d0d-425e-b6dd-7dbc5f6e6527",
                "70f55855-6f81-45a8-bd40-d8b60ae45b82"
              ]
            }
          ]
        }
      ]
    }
  ]
}

To track the status of the migration, make the following API call:
```
GET https://<nsx-mgr>/api/v1/nvds-urt/status-summary/<precheck-id>
```
When the host is ready for migration, the precheck_status changes from APPLYING _TOPOLOGY to READY and host status is set to UPGRADE_READY.
Refer to the NSX-T Data Center API Guide guide for more information on API parameters.
Place the ESXi host in maintenance mode from vCenter.
To initiate the N-VDS to VDS migration, make the following API call:
```
POST https://<nsx-mgr>/api/v1/transport-nodes/<tn-id>?action=migrate_to_vds
```
The hosts are migrated asynchronously. You can upgrade multiple transport nodes in parallel by calling the API for a desired set of hosts. Services like DRS continue to run as expected during the process of migration.

Make the following API call to track the status of migration:

GET https://<nsx-mgr>/api/v1/nvds-urt/status-summary/<precheck-id>

The host migration_state changes from UPGRADE_IN_PROGRESS to SUCCESS after a successful migration.

Example response:

{
  "precheck_id": "c306e279-8b75-4160-919c-6c40030fb3d0",
  "precheck_status": "READY",
  "migration_state": [
    {
      "host": "65592db5-adad-47a7-8502-1ab548c63c6d",
      "overall_state": "UPGRADE_READY"
    },
    {
      "host": "e57234ee-1d0d-425e-b6dd-7dbc5f6e6527",
      "overall_state": "UPGRADE_READY"
    },
    {
      "host": "70f55855-6f81-45a8-bd40-d8b60ae45b82",
      "overall_state": "SUCCESS"
    }
  ]
}

In the event of failures, the overall_state changes to FAILED, indicating the reason for the migration failure. Run the migrate_to_vds action to run the migration task again.

For stateless hosts:
1. Extract the host profile from the migrated host and attach it to the cluster.
2. Reboot the remaining hosts in the cluster.

Perform the migration from the NSX Manager CLI.

To verify that the hosts are ready for migration, run the following command and run a pre-check:
```
vds-migrate precheck
```
Sample output:
```
 Precheck Id: 0a26d126-7116-11e5-9d70-feff819cdc9f
```
Address any configuration inconsistencies and run the pre-check again.

To retrieve the recommended topology, run the following command:

vds-migrate show-topology

Sample output:

Precheck Id: 137d2a87-0544-4914-829d-d8b7e33b13f2
       NVDS: nvds1(19cca902-9455-4316-92e2-65f4f5b4b138)                          
       Compute Manager Topology:                                                  
       [                                                                          
           {                                                                      
               "compute_manager_id": "fd37ed6e-0eae-4d65-b29a-d40eee1d5d47",      
               "dvswitch": [                                                      
                   {                                                              
                       "transport_node_id": [                                     
                           "4d011ade-a010-4eea-b45a-b2569c0bb9ad"                 
                       ],                                                         
                       "data_center_id": "datacenter-3",                          
                       "vmknic": [],                                              
                       "vds_name": "CVDS-nvds1-datacenter-3"                      
                   }                                                              
               ]                                                                  
           }                                                                      
       ]

Run the following command to create a VDS with the recommended topology:
```
vds-migrate apply-topology
```
Log in to vCenter Server and verify that the VDS is created.

To initiate the N-VDS to VDS migration, run the following command:

vds-migrate esxi-cluster-name <cluster-name>

Sample output:

 VDS Migration Done:                                                     
   3 Transport-Nodes Migrate Successfully          
   0 Transport-Nodes Migrate Failed

You can also use the transport node ID to initiate migration:

vds-migrate tn-list <file-path>

where <file-path> includes the Transport Node IDs.

Sample output:

nsx-manager-1> vds-migrate tn-list /opt/tnid
       VDS Migration Done:
       3 Transport-Nodes Migrate Successfully
       0 Transport-Nodes Migrate Failed

Starting NSX-T Data Center 3.1.1, you can use the NSX Manager to prepare your hosts for migration and then migrate to VDS as part of the host OS upgrade, using vSphere Update Manager.
To migrate your host switch as part of the host OS upgrade using vSphere Update Manager, you need vCenter Server 7.0.U2.
Note: The ESXi hosts must be upgraded across ESXi update releases for this migration to be triggered. For example,
- Upgrade from ESXi 7.0 to ESXi 7.0 U2 - switch migration can be triggered.
- Upgrade from ESXi 7.0 U2 to ESXi 7.0 U2a - switch migration cannot be triggered as upgrade is within the same ESXi update version.
1. Log in as a local admin user to an NSX Manager at https://nsx-manager-ip-address/login.jsp?local=true.
2. Select System > Quick Start.
3. Click Get Started to prepare your hosts for migration from N-VDS to VDS.
4. Click Precheck to verify if the hosts are ready for migration.
5. Address any configuration inconsistencies and run the pre-check again.
6. Review the recommended network topolgy.
7. Click Create to prepare the selected hosts for migration by creating a corresponding VDS switch in vCenter Server.
8. Log in to vCenter Server and upgrade your ESXi hosts using vSphere Update Manager. The switch migration is completed when the host OS upgrade is done.
9. Monitor the progress of migration from the Monitor tab.

Move the migrated hosts out of maintenance mode. This step is not required for migration of host switch as part of host upgrade using vSphere Update Manager.