In NSX-T Data Center 3.2.2 and later, when you migrate a user-defined topology, you can choose the Configuration and Edge Migration mode. This mode migrates configurations, bridges the NSX-V logical switches to their corresponding NSX-T Data Center segments, and migrates Edge nodes for north-south traffic cutover.

Note: This is a tech preview feature in NSX-T Data Center 3.2.2. This feature is fully supported in NSX-T Data Center 3.2.3 and later.
Note: This migration mode requires dedicated hosts ready to be added to the NSX cluster. If new hosts are not available, hosts from NSX-V can be re-used. For more information, see the sections "(Optional) Re-using an NSX-V Host as an NSX Transport Node" and "(Optional) Adding an NSX Transport Node After the Migrate Edges Step Has Started" below.

End-to-end Workflow of Configuration and Edge Migration

Perform the following steps when you choose this mode:

  1. Prepare the NSX-V environment. See Preparing the NSX-V Environment for a User-Defined Topology Lift-and-Shift Migration.
  2. Prepare the NSX-T Data Center environment. See Preparing the NSX-T Data Center Environment for a User-Defined Topology Migration.
  3. Perform the migration steps Import Configuration, Translate Configuration Layer 2, Resolve Configuration Layer 2, Migrate Configuration Layer 2, and Check Realization Layer 2. The transport zones and segments are created and ready to be used.
  4. From the NSX Manager UI, configure NSX on ESXi hosts in the target site. Choose the correct transport zone for each host switch so that VMs migrated to the hosts will be connected to the correct segments. If a VTEP IP pool is used to configure NSX, make sure that there is no overlap in IP addresses between this IP pool and IP pools configured on NSX-V.
  5. On NSX, create a topology that maps to the NSX-V topology, including tier-0 and tier-1 gateways.
  6. Perform the migration steps Define a Topology, Translate Configuration Layer 3 and Above, Resolve Configuration Layer 3 and Above, Migrate Configuration Layer 3 and Above, Check Realization Layer 3 and Above, and Migrate Edges.
  7. In the Migrate Workloads step, the following methods are available to migrate workload VMs:
    • HCX - For more information, see the HCX documentation.
    • vMotion - Follow the instruction in the section "Migrating Workload VMs" below.
  8. Verify that everything works as expected.
  9. Perform post-migration tasks to clean up the source site on NSX-V if needed.

Migrating Workload VMs from HCX

Note: Verify that your version of HCX supports this capability. If HCX is not available, see the section "Migrating Workload VMs" below for information on how to migrate workload VMs.

HCX can migrate VMs by group. To migrate VMs from HCX, first perform the migration steps from NSX Manager until the last step, Migrate Workloads. Then migrate the VMs from HCX. When the VMs are migrated, click Finish on the Migrate Workloads screen in NSX Manager.

Migrating Workload VMs

If you do not migrate workload VMS using HCX, you can follow the steps in Migrate Workloads in Lift-and-Shift Migration.

(Optional) Re-using an NSX-V Host as an NSX-T Data Center Transport Node

If you want to re-use an NSX-V host, follow the steps below to first prepare the host as an NSX-T Data Center transport node.

If the migration target VC is the same as the source VC:
  1. Enter the host into maintenance mode in VC.
  2. Move the host out of its cluster so that it becomes a standalone host. Uninstall NSX-V from the host.
  3. Exit the host out of maintenance mode.
  4. In NSX Manager UI, find the host in System > Fabric > Nodes > Host Transport Nodes (if the NSX-T version is 3.2.0 or 3.2.1) or System > Fabric > Hosts (if the NSX-T version is 3.2.2 or later). Add the VDSes with the correct transport zones and host-switch uplink profiles. Wait for the state of the node to display Success.
If the migration target VC is different from the source VC:
  1. Enter the host into maintenance mode in VC.
  2. Move the host out of its cluster so that it becomes a standalone host. Uninstall NSX-V from the host.
  3. Move the host out of all the VDSes in the source VC.
  4. Note down the host IP and then remove the host from the inventory in the source VC.
  5. Add the host to a cluster in the target VC and then to the VDSes in the target VC.
  6. Exit the host out of maintenance mode.
  7. In NSX Manager UI, find the host in System > Fabric > Nodes > Host Transport Nodes (if the NSX-T version is 3.2.0 or 3.2.1) or System > Fabric > Hosts (if the NSX-T version is 3.2.2 or later). Add the VDSes with the correct transport zones and host-switch uplink profiles. Wait for the state of the node to display Success.

It is recommended to re-use an NSX-V host before the Migrate Edges step starts. If you want to re-use an NSX-V host after the Migrate Edges step has started, follow the steps in this section and then follow the steps in “(Optional) Adding an NSX-T Data Center Transport Node After the Migrate Edges Step Has Started”.

(Optional) Adding an NSX-T Data Center Transport Node After the Migrate Edges Step Has Started

It is recommended to add all NSX-T Data Center Transport Nodes to the target NSX-T Data Center system before the Migrate Edges step starts. Follow the steps below as a workaround to add an NSX-T Data Center transport node after the Migrate Edges step has started.

  1. In NSX Manager UI, go to System > Fabric > Nodes > Host Transport Nodes (if the NSX-T version is 3.2.0 or 3.2.1) or System > Fabric > Hosts (if the NSX-T version is 3.2.2 or later) and copy the node's UUID.
  2. Use ssh to log in to the NSX Manager where you launched the migration.
  3. Search for the host's IP in /var/log/migration-coordinator/v2t/nsxv-config/hosts.json and copy the moId (for example, host-12). If no host is found in the file, find the host's moId through https://<VC-IP>/mob.
  4. Run the following commands:
    cd /opt/vmware/migration-coordinator-tomcat/bin/v2t/config-collector

python3 vc_collector.py -s <VC-IP> -o <VC-HTTPS-port> -u <VC-user-name> -t /var/log/migration-coordinator/v2t/nsxv-config/ -c /var/log/migration-coordinator/v2t/config.json -hId <TN-uuid> -hmoId <host-moId>
    Note: <VC-HTTPS-port> is 443 by default. For example, 
    python3 vc_collector.py -s 10.78.129.191 -o 443 -u [email protected] -t /var/log/migration-coordinator/v2t/nsxv-config/ -c /var/log/migration-coordinator/v2t/config.json -hId 1bad5da6-8093-4496-a910-3dc224e6ac11 -hmoId host-12
  5. Run the following commands:
    cd /opt/vmware/migration-coordinator-tomcat/bin/v2t/config-migrator

python3 main.py -c /var/log/migration-coordinator/v2t/config.json -s accept-tn -t tn -i <TN-uuid> runtime
    For example, 
    python3 main.py -c /var/log/migration-coordinator/v2t/config.json -s accept-tn -t tn -i 1bad5da6-8093-4496-a910-3dc224e6ac11 runtime
    If you are prompted for the authentication token of NSX-V manager, you can get the token by running the following command: 
    curl -i -k -u <admin-user> -X POST https://<nsx-v-ip>/api/2.0/services/auth/token?expiresInMinutes=720

    Note: <admin-user> is the administrator account of NSX-V manager and <nsx-v-ip> is the NSX-V manager's IP address.

    This step will take a long time when the first transport-node is accepted because it needs to power on the NSX-V controllers. This step will fail if no NSX-V controller can be powered on and is in the connected state. In this situation, fix the NSX-V controllers to make sure that at least one NSX-V controller is in the connected state. Then retry this step.