With the NSX 4.0.1.1 release, Migration Coordinator adds two game-changing features that help simplify workload migration in the case of lift and shift migration mode. These features build on top of the User Defined Topology mode of migration and add one more config mode. Folks familiar with the User Defined Topology will find the workflow very similar with the added benefit of simplified workload migration, leveraging HCX.

In this blog post, we will look at this new feature and how to take advantage of it. Please check out the resource links for more information on Migration Coordinator. We will start with a high-level overview before digging into the details.

Migration Coordinator

Migration Coordinator was introduced with NSX-T 2.4 to enable customers to migrate from NSX for vSphere to NSX-T Data Center. It’s a free, fully supported tool that’s built into NSX-T Data Center. Migration Coordinator is flexible with multiple options enabling multiple ways to migrate based on customer requirements. The first release provided a way to migrate everything, including config, workloads, and hosts in place using the same hardware if the deployed topology matched the supported topologies. Starting with the NSX-T 3.2 release, Migration Coordinator offered User Defined Topology mode, removing the restrictions on the supported topologies.

User-Defined Topology: User Defined Topology allows flexibility in terms of topology used for migration. In this mode, the user has the flexibility to create a topology in NSX-T and specify how the existing NSX for vSphere objects are mapped to the new NSX-T objects. For example, the user has the flexibility to map the Edge on NSX for vSphere with the corresponding objects such as a T0 onto NSX-T. This mapping is used by the Migration Coordinator to migrate the configuration over from NSX for vSphere to NSX-T. This mode supports both:

In-place (migrating the configuration along with the workloads and hosts)
Lift-and-shift (migration of just the configuration and allowing flexibility in timing the workload migration)

User Defined Topology’s lift and shift mode ensures that there is no compromise in security posture during the migration, including the workload migration, even though the actual workload migration is performed outside the migration coordinator.

Challenges with User-Defined Topology’s Lift and Shift mode:

Bridging: For some, migration may take more than a single downtime window. There may be a need to establish connectivity between the workloads that are on a logical switch on NSX for vSphere and its corresponding segment on NSX. In such cases, deploying a bridge is essential. One option is to use the NSX Edge bridge. However, a single NSX Edge bridge can only bridge a single segment. For deployments at scale, this can pose a challenge.

Workload migration: To ensure security posture, Migration Coordinator pre-creates logical ports on the NSX side. These ports are created via API calls to the migration coordinator that includes UUIDs of the corresponding workload. The expectation is to land each workload on its designated port. This can only be achieved by running vMotion via API. For those who are not familiar with scripting, and especially for deployments at scale, this could turn out to be a hurdle.

With the release of NSX 4.0.1.1, Migration Coordinator brings the simplicity of in-place migrations that are completely driven by Migration Coordinator to the lift and shift migrations where workload migration is driven by the end user.

User Defined Topology – Configuration and Edge Migration Mode

In this latest release, Migration Coordinator introduces a third mode to the User Defined Topology mode: Edge and Config Migration Mode. With this new mode, Migration Coordinator removes the need to establish bridging for the segments and one can leverage HCX to simplify workload migration without compromising security posture.

Workflow

At a high level, this mode consists of six simple steps that include a provision to map the objects from NSX for vSphere with NSX objects. These are the high-level steps of User Defined Topology – Edge and Config Migration mode:

Prerequisites
1. Check whether the prerequisites are met. This includes checking items such as versions used, mapping NSX for vSphere to NSX, a one-time import, and check of configuration from NSX for vSphere. This step is called “Import Configuration” on the migration coordinator GUI.
Migrate and check realization status of L2 elements
Define Topology
1. Mapping the DLRs and ESGs on the NSX for vSphere side with the corresponding T0s and T1s on the NSX side
Migrate and check realization status of L3 elements
Edge Migration
Workload Migration

The following image shows the overall steps:

Layer 2 and Layer 3 stages are expanded, similar to the User Defined Topology, to allow granular control over config translation, user inputs, and realization checks. Please check out the blog on User Defined Topology mode for more details. Edge Migration stage cuts over the north / south connectivity from NSX for vSphere to NSX and also bridges every NSX for vSphere logical switch with its corresponding segment on NSX.

The following image provides a more detailed view of all the steps – including the expanded Layer 2 / 3 stages:

In the following sections, we will take a close look at some of the stages relevant to “Configuration and Edge Migration” mode.

Selecting the right mode to leverage HCX
Migrate Edges
Migrate Workloads

Selecting the right mode to leverage HCX

Configuration and Edge Migration mode is under the User Defined Topology Mode. Click on “User Defined Topology” under “GET STARTED” on NSX for vSphere migration mode.

This will present three migration options:

Complete Migration
Configuration Migration
Configuration and Edge Migration

Select Configuration and Edge Migration mode. Note the call out for this mode specifies that this is the recommended mode to be used with HCX. Also, note that this mode will require HCX 4.5.

Migrate Edges

Migrate Edges phase, in this mode, not only allows moving the gateway over from NSX for vSphere to NSX, but also bridges every logical switch on the NSX for vSphere side with the corresponding segment on NSX. The panel for Migrate Edges phase is similar to the previous modes, with a “START” button. Note: This phase still has a rollback option, if needed.

Edge migration phase adds the VTEP IPs of all the NSX for vSphere hosts, to the TEP tables of all of the NSX nodes, hosts, and edges. This allows NSX to be aware of all the hosts and hence communicate with both the ones on NSX and the ones from NSX for vSphere. The following image shows a VTEP IP of one of the nodes on NSX for vSphere, added to an edge node on NSX.

VTEP IP of a node in NSX for vSphere:

Added to an Edge node on NSX:

When using the Configuration and Edge Migration mode, there is no need for an additional NSX bridge or additional edges to bridge the logical segments on NSX for vSphere with the segments on NSX anymore. This is automatically done by the migration coordinator.

Migrate Workloads

Using the Configuration and Edge Migration mode allows users to leverage HCX for workload migration. During the migrate workloads stage, users will move to the HCX GUI for the actual workload migration.

At this point, leverage HCX to select and migrate the VMs from NSX for vSphere to NSX.

Once the workload migration is done, users will need to go back to the migration coordinator UI and click “Finish” to finalize and finish the migration.

Understanding Workload Migration for NSX V2T (in the HCX User Guide)

Conclusion

With the release of NSX-T 4.0.1.1, Migration Coordinator expands on the User Defined Topology mode to include Configuration and Edge migration mode. Customers will now be able to simplify workload migration in the lift and shift use case using Migration Coordinator. In this mode, Migration Coordinator automatically bridges all the logical switches with the corresponding segments on NSX and also allows leveraging HCX for workload migration.