VMware NSX-V to NSX-T Migration Guide
Purpose of this Document
VMware NSX-T has arrived! The message was loud and clear during VMworld 2019. The latest NSX-T 3.0 release is acting as a catalyst to NSX-T’s growth that was already on an exponential growth trajectory with the NSX-T 2.5 release and the recently released 2.0 version of the NSX-T Design Guide. Gone are the days of questions comparing NSX-T with NSX for vSphere (NSX-V). Top of mind question for customers today are who have adopted NSX-V and how do I upgrade my NSX-V based data center to NSX-T?
There are several ways to migrate from NSX-V to NSX-T. In this white paper, we will look at various approaches available for migration. This white paper will also focus on Migration Coordinator, a tool built into NSX-T that simplifies in place upgrade of NSX-V based infrastructure to NSX-T.
This white paper is primarily for the benefit of customers who are currently using NSX-V.
This document focuses on the options available to migrate from NSX-V to NSX-T. Knowledge of both of NSX-V and NSX-T is essential for a successful outcome. Please check out the design guides for both versions of NSX.
Additionally, try out NSX-T in a lab environment, to get hands on experience with the product, before embarking on a migration project.
High Level Options to Migrate to NSX-T
At a high level, we have two primary approaches when migrating to NSX-T (Figure 1: High Level Migration Approaches).
- In Parallel
- In Place
In Parallel Migration In Parallel Migration
Figure 1: High Level Migration Approaches
In Parallel Migration
In this method, NSX-T infrastructure is deployed in parallel along with the existing NSX-V based infrastructure. While some components of NSX-V and NSX-T, such as management, could coexist, compute clusters running the workloads would be running on separate hardware.
There are some of the advantages with this approach, namely flexibility. Migration of the workload in this approach could take couple of different approaches.
- New workloads are deployed on NSX-T and the older workloads can die over time.
- Lift and shift workloads over to the new NSX-T infrastructure.
Either case allows for planning the migration based on individual tenant and workload requirements and migrate one piece at a time.
When running NSX-V and NSX-T in parallel, based on the desired approach for migration, they could stay as independent entities or create cross-connectivity between the two domains using methods such as NSX Bridging.
There are two approaches available for Bridging the two domains:
- Independent Bridging
- NSX-T Only Bridging
In the independent bridging approach, both NSX-V and NSX-T would enable bridging that is independent of each other, but both connected to the same VLAN backed network. This model allows more than 1 network to be bridged at the same time, if the number of such networks is within the scale limits of bridging for NSX-V and NSX-T.
For scale limits, refer to the config max tool.
NSX-T Only Bridging
In this approach, an NSX-T Bridge may be placed on a host that is prepared for NSX-V. This allows the Bridge to take advantage of decapsulation of VXLAN frames that happens on the ESXi host and only needs to perform Geneve encapsulation. However, with this approach, only one network may be bridged per Edge VM.
Downsides to In Parallel Migration
While the in parallel approach has benefits such as planning and migration on demand that’s based on workload requirements, there are certain downsides to it that need to be considered.
- Recreate topology and policy: Currently, topology and policy from the existing NSX-V cannot be leveraged. Instead, it needs to be created on the new NSX-T based infrastructure.
- Needs separate hardware (HW): NSX-T and NSX-V cannot coexist on a single host.
Hence, there is a need for separate HW to run NSX-T based compute clusters on. Separate does not necessarily mean new. Some customers have leveraged existing HW to carve out resources that can be released from NSX-V and reallocated to NSX-T. This approach is slower and requires moving over HW resources to NSX-T as workloads are migrated to NSX-T. Another approach is to go with new HW which could work in cases where the migration aligns with a HW refresh cycle. In this case, NSX-T could be installed on the new HW.
- vMotion: vMotion may be needed to move the existing workloads; however, vMotion has certain limitations which could result in downtime based on the type of vMotion approach available. These limitations should be taken into consideration. Check out he KB article 56991, vMotion Between VDS/VSS and N-VDS (NSX-T switch), for more details.
- Managing Policy: Customers need to consider that a workload may exist in any of the two infrastructures. There may be a need for adding or removing new workloads and a need to change the security posture. Care should be taken to update both infrastructures to ensure that these modifications do not compromise the security posture.
- Managing two infrastructures: Customers will have to plan for supporting two different environments for the duration of the migration.
In Place Migration
Another approach to migrating over to NSX-T is using the NSX-T’s built in Migration Coordinator tool. The Migration Coordinator tool, available since the 2.4 release of NSX-T, helps in replacing NSX-V, in place on existing hardware, with NSX-T. This tool also imports the existing configuration to apply on the new NSX-T based infrastructure.
The Migration Coordinator tool also supports Maintenance Mode, that allows automatic placement of ESXi host into maintenance mode and vMotion VMs off from the host before replacing the VIBs. This feature was introduced in the 3.0 release of NSX-T. The end goal of this tool is to completely transform your existing NSX-V into an NSX-T based infrastructure. Later sections of this white paper focus on the Migration Coordinator tool.
Migration Steps in General
For both in parallel and in place migration, the following are recommended steps:
Before starting off on migration, get to know both NSX-V and NSX-T. Since customers are coming from an NSX-V background, they should already know NSX-V.
For NSX-T, we recommend building a lab infrastructure and getting to know the platform, hands on. At the very least, try out the Getting Started with NSX-T hands-on labs.
As mentioned previously, check out the design guides for both the product lines to understand their full details:
Plan Your Migration Approach
Understand the workloads that are running on NSX-V. This will help figure out whether a quick in-place migration or a longer in parallel approach would be better.
Install NSX-T Manager Appliances and Edges
For both the in-parallel and in-place approaches, start off the migration process by installing the NSX-T Manager Appliances. Some of these components may share resources with the existing NSX-V infrastructure. For example, NSX-T Manager Appliances may be installed in the same management cluster that the older NSX-V Manager components reside on.
Note that NSX-T Manager is installed via an OVA and not Manager UI.
Import Configuration from NSX-V
Based on the approach towards migration, the next step would be to import the configuration from the existing NSX-V infrastructure.
In the case of in-place migration with Migration Coordinator, importing configuration is an automated process.
For the in-parallel migration, there are several approaches based on the migration strategy. Some customers like to start off fresh using a different design and security posture and move the workloads over. While others like to keep the new NSX-T infrastructure consistent with the existing infrastructure. With either approach, the new NSX-T infrastructure needs to be built up with the right networking components and security posture. Some parts of this migration, such as importing security posture, could potentially be automated.
Apply Configuration on NSX-T
The imported configuration needs to be applied on the NSX-T infrastructure. Again, with the Migration Coordinator tool, this step is a single click automated process. With the in-parallel approach, this step may be scripted to go along with the import phase of the migration.
At this point NSX-T infrastructure should be up and running with the right configuration and ready to migrate workloads. Migrating workloads over could mean downtime based on the approach taken to migrate.
The next phase in Migration Coordinator is to move the N/S connectivity over to NSX-T.
In this special case, NSX-T during migration, is able to talk to VxLAN and not just Geneve. Because of this feature, NSX-T edges can talk to workloads on the existing NSX-V infrastructure and communicate with the existing NSX-V based hosts and their VTEPs.
Final step in this migration process is to migrate the hosts over to NSX-T. This is the final step and there is no revert at this point.
Migration Coordinator Tool
This tool was introduced with the NSX-T 2.4 release. Based on the feedback from the 2.4 release, the NSX-T 2.5 release improved the ease of use and health check capabilities of the NSX-T Migration Coordinator tool. The following are steps to take during NSX-T migration:
Learn and try out NSX-T first
–Learn more with curated learning paths on NSX Tech Zone
–Try out for free with an NSX-T Hands-on Lab
- Prepare NSX-V for Migration
- Install NSX-T Manager appliances: because it’s a tool within NSX-T, duh!
- Import configuration from NSX for vSphere
- Check and resolve any configuration related issues migrating from NSX-V to NSX-T
- Migrate Configuration
- Migrate Edges
- Migrate Hosts
- Finish Configuration
Let’s take a look at each of the steps as it relates to Migration Coordinator tool.
Prepare NSX-V for Migration
Before starting with the migration process using Migration Coordinator, ensure NSX-V is ready for migration. There are number of checks that need to be performed in this stage including:
- Making sure the NSX-V is in a stable state
- Making sure VXLAN port is set to 4789
- Ensure the export version of DFW is set to 1000 etc.,
For a full list of checks, refer to the Migration Coordinator guide. Specifically, read the section Prepare NSX Data Center for vSphere Environment for Migration (NSX-T 2.5).
Install NSX-T Manager Appliances
Migration Coordinator is a tool that is available within the NSX-T Manager appliance. Hence, NSX-T Manager Appliances need to be installed to start the migration process using this tool. This tool was introduced with NSX-T 2.4. However, the recommended version is NSX-T 2.5 release or later as they have several usability and health check enhancements.
Note: While the recommended approach for production workloads is to use a quorum of 3 NSX-T Manager Appliances, it may be acceptable, based on the type of workload, to start with just one. Implications of having only one NSX-T Manager should be considered, before taking this approach.
Create IP Pool for Tunnel End Points
After the NSX-T Manager Appliance installation, create an IP Pool for Tunnel End Points.
Figure 2: Create IP Pool for TEP
Install the required number of edges with the amount of resources that matches the existing NSX-V deployment.
Use the Migration Coordinator Guide’s “Determining NSX Edge Requirements” (NSX-T version 2.5) section to figure out the right number of edges and the right amount of resources for each edge.
Resolve Configuration stage of the Migration Coordinator helps validate whether the Edges deployed are of the right size.
Add Compute Manager
Add Compute Manager that points to the vCenter that’s attached to the NSX-V that needs to be migrated.
Click on System -> Fabric -> Compute Managers -> Add
Figure 4: Add Compute Managers — 1
Provide the details of the vCenter that’s attached to the NSX-v that needs to be migrated:
Accept the thumbprint from the vCenter:
At this point, you may have a pop window that needs to be resolved — simply provide username and password of vCenter and click resolve.
Confirm vCenter is connected.
MIGRATION GUIDE |
Start Migration Coordinator Service
Migration Coordinator is available from the NSX-T UI under System Tab on top and Migrate on the left side menu. However, the service for Migration Coordinator is not started by default. Hence, going to the Migrate page before starting migration coordinator service, will display a message on top of screen stating that the migration coordinator needs to be enabled.
Figure 10: Migration Coordinator Service is disabled by default
This tool needs to be enabled from CLI. Login to the NSX-T Manager cli and run the following command to enable it:
nsx-manager> start service migration-coordinator
Once the service is enabled, Migrate page on NSX-T UI changes to display the Migration options.
Migration Coordinator Steps:
To start the Migration, click on the “GET STARTED” button. A couple of things to note here:
- No changes are allowed during the migration process.
- Even though this is technically the start of the migration process, no changes have been made on the NSX-V side so this process may be abandoned at this point without any negative impact.
Migration Coordinator has 5 main steps:
- Import Configuration
- Resolve Configuration
- Migrate Configuration
- Migrate Edges
- Migrate Hosts
In the following sections, we take a close look at each of these steps.
Import configuration step consists of two sub steps
- Authenticate to NSX-V
- Import Configuration
Provide the NSX for vSphere details. Use the vCenter details provided in the earlier step. If not done yet, use the ADD NEW button for the vCenter field to add vCenter details.
Once all the details are provided and verified, click on AUTHENTICATE.
Confirm that the authentication to NSX for vSphere was successful.
Figure 14: Successful Authentication to NSX for vSphere
Second step in this process involves importing configuration. Click on START button to start importing configuration.
Click on the IMPORT button to confirm importing the configuration.
At this point, Migration Coordinator imports the existing configuration from the NSX for vSphere. This does not make any changes to the NSX for vSphere so this could be used for a quick check on the Migration Coordinator readiness of any setup.
View Imported Topology
Once the Migration Coordinator imports the configuration, there is an option to view the existing NSX-v topology by clicking on the “View Imported Topology” link:
To go to the next step of the Migration Coordinator, click on the “CONTINUE” button:
This will take us to the next step that helps in resolving any configuration related issues.
This stage is focused on resolving any configuration related issues. To resolve either accept the recommended value or where applicable and available tune it to match the required values.
Following are some example of the items that may need to be resolved.
One of the items under L2 category is a callout for Host that won’t be migrated because NSXV is not installed on it. In this case, user interaction is limited to simply to accepting the information.
To see the details, click on the above Message.
Click “ACCEPT” to accept the recommendation.
Some of these messages may need user interaction. For example, VTEP VLAN id for NSX-T Edge Transport Nodes. This may need a change based on requirements:
Click on the Message “VTEP VLAN id for NSX-T Edge Transport Nodes” to make a change:
After all the changes/reviews within a category, “SUBMIT” button that shows up on top right should be clicked to record the inputs.
Maintenance Mode Options
One of the options under the resolve configuration page is to help select “Automated” vs “Manual” Maintenance Mode.
Clicking on the message allows the user to configure whether the Maintenance Mode should be in Automated mode or Manual. In the Automated Maintenance Mode, which is the recommended mode, ESXi hosts are automatically placed in maintenance mode and the VMs are also migrated automatically. In the Manual Maintenance Mode, Migration Coordinator will place the ESXi host in maintenance mode but will wait for user intervention to migrate the VMs out of the host.
Once all the changes are accepted and submitted, we can move on to the next step of migrating the configuration.
This stage migrates the configuration over from NSX for vSphere to NSX-T. Any changes that were done during the Resolve Configuration stage are incorporated into this migration.
Once the Migration of Configuration finishes, it displays a table of object types and their mapping moving from NSX for vSphere to NSX-T.
At this point, we can move to the next phase “Migrate Edges” by clicking on “CONTINUE”
Edge Migration straight forward, simply click on “Start”:
This step does expect deployed correctly sized NSX-T Edges, that are suitable to support NSX-T version of the topology deployed on NSX-V.
Figure 29: Migrate Edges — Rollback
UI driven Rollback is supported, even after migrating the Edges. Simply click on “ROLLBACK” if planning to rollback at this stage. Clicking Continue will move us to the last stage of Migration which is Migrating Hosts.
This is the last step of Migration. This pane offers several options including:
- Whether the Migration should happen serially (one host at a time) or in parallel (all the hosts at the same time)
- Where there should be a pause between each cluster
- And importantly, since the NSX-T 3.0 release, whether the Migration should use Maintenance mode.
Select the right options based on the requirements and click start.
Note: Rollback at this point is not available. If rollback is desired, one way to achieve that would be to use a smaller 2 node test cluster to try the migration out on, enable pause between clusters, and then continue or rollback based on the outcome on that first test cluster.
There are multiple ways to Migrate from NSX for vSphere to NSX-T Data Center. Migration Coordinator provides a simple automated in-place approach with minimal downtime and using the same hardware.
Design Guides on NSX-T
Try out NSX-T for free