There are three methods you can use to migrate your 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-T Distributed Virtual Port Groups. Any changes to the segments on the NSX-T network are synchronized in vCenter Server.

To migrate your N-VDS on ESXi hosts to NSX on VDS choose:

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.

  • In NSX-T 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 3.1.1 without named teaming.

  • 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.

  • N-VDS to NSX-T Data Center on VDS 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

  • 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.

Note:

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

Option 1: Use API to Migrate Host Switch to vSphere Distributed Switch

You can use the NSX-T Data Center API to migrate a host switch to a vSphere distributed switch (VDS).

To migrate your host switch using API calls, perform the following steps.

Procedure

  1. Review the requirements to migrate to a VDS 7.0 host switch in the Prerequisites section.
  2. 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" }
  3. Address any configuration inconsistencies and run the precheck again. Running precheck after addressing configuration inconsistencies will not show inconsistent configurations again in the response.
    Starting with 3.2.1, a precheck run will not fail in case of incompatible configurations between transport nodes within an NSX-T Data Center environment. 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. Set the value for the tolerate_different_configurations parameter based on whether or not you want the topology to include all combinations of different configurations. Refer to the NSX-T Data Center API Guide for more information. The default value for tolerate_different_configurations is true.
    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.
  4. 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"
            }
        ]
    }
  5. For stateless hosts, nominate one of the hosts as the source host and initiate the migration.
  6. 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": "VDS-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": "VDS-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": "VDS-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"
            }
        ]
    }
  7. 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 rename the VDS in the recommended topology with a new name and cannot use the name of 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"
                  ]
                }
              ]
            }
          ]
        }
      ]
    }
  8. 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.

  9. Place the ESXi host in maintenance mode from vCenter.
  10. 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.

  11. 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.

  12. 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.

What to do next

After the migration completes, you can perform your upgrade.

Option 2: Use CLI to Migrate Host Switch to vSphere Distributed Switch

You can use the NSX-TNSX-T CLI to migrate a host switch to a vSphere distributed switch (VDS).

To migrate your host switch using CLI calls, perform the following steps.

Procedure

  1. Review the requirements to migrate to a VDS 7.0 host switch in the Prerequisites section.
  2. 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
  3. Address any configuration inconsistencies and run the pre-check again.
  4. 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": "VDS-nvds1-datacenter-3"                      
                       }                                                              
                   ]                                                                  
               }                                                                      
           ]
  5. Run the following command to create a VDS with the recommended topology:
    vds-migrate apply-topology
  6. Log in to vCenter Server and verify that the VDS is created.
  7. 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

What to do next

After the migration completes, you can perform your upgrade.

Option 3: Use UI to Migrate Host Switch to vSphere Distributed Switch

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 using the UI, perform the following steps.

Note: You must upgrade the ESXi hosts for this migration to trigger. Note that the migration is triggered only for ESXi 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. ESXi version is specified as X.Y.Z-U.P where,
  • X = Major

  • Y = Minor

  • Z = Maintenance

  • U = Update

  • P = Patch

For example, migration will trigger if ESXi is upgraded from 7.0.2 to 7.0.3, but it will not trigger if ESXi is upgraded from 7.0.2-0.0 to 7.0.2-1.0.

Procedure

  1. Review the requirements to migrate to a VDS 7.0 host switch in the Prerequisites section.
  2. Log in as a local admin user to an NSX Manager at https://nsx-manager-ip-address/login.jsp?local=true.
  3. Select System > Quick Start.
  4. Click Get Started to prepare your hosts for migration from N-VDS to VDS.
  5. Click Precheck to verify if the hosts are ready for migration.
  6. Address any configuration inconsistencies and run the pre-check again.
  7. Review the recommended network topolgy.
  8. Click Create to prepare the selected hosts for migration by creating a corresponding VDS switch in vCenter Server.
  9. 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.
  10. Monitor the progress of migration from the Monitor tab.

What to do next

Optional: 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.