How to migrate NSX-V to NSX-T 3.2.0.1 with the Migration Coordinator [Fixed topology]
Ever needed to migrate NSX-V to NSX-T? During this post, i’m going to break down the steps for migrating a NSX-V Data Center Environment to NSX-T. This migration is based on one of the available fixed topologies in the NSX Migration Coördinator.
Update 28-5-2023: I have published a new blog post that covers the User Defined Migration mode. Click here to read the new blog post.
Table of Contents
Lab overview
The lab contains of the following:
- 1 management vCenter (vc01-mgmt.vk.lan) with 3 nested ESXi hosts (vSphere version 7)
- 1 workload vCenter (vc02-mgmt.vk.lan) with 3 nested ESXI hosts (vSphere version 7)
- vSAN is the primary storage on both of the vCenters
- NSX-V manager appliance is deployed in vc01 but registered to vc02 (VMware NSX for vSphere 6.4.13)
Supported Topologies
There are 5 supported topologies available when it comes to a Fixed Topology migration mode..
In my case, the following topology (#1) was configured in the nested NSX-V lab.
See the available supported topologies: link
Preparations
Prepare NSX-T environment
Deploy an NSX-T Manager
We need to deploy a new NSX-T manager and add the vCenter used by NSX-V as a compute manager in NSX-T.
Do not deploy additional appliances to form a cluster, this should be done after a successful migration.
Note: if you are planning to deploy the NSX-T manager on an ESXI host that is part of a NSX-V cluster, use this article to avoid connectivity issues on management VMs after the migration: link
In my lab, I have deployed in the management vCenter a new NSX-T manager as shown below.
After the deployment of the NSX-T manager, I need to register the workload vCenter as compute manager.
Make sure that the registration status of workload vCenter is Registered and connection status is UP.
Create an IP pool for Edge tunnel End Points
We need to create an IP pool in the NSX-T manager that we will use for the NSX-T Edge nodes.
Make sure that this IP range that you defined in the IP pool is not in use.
Deploy NSX Edge nodes as VM
Lets start with deploying a NSX-T Edge node for the North South traffic. This NSX-T Edge node cannot be deployed from the NSX-T Manager, but must be deployed by the OVA file that is made available by VMware.
Make sure to assign the first NIC (Network 0) to the management portgroup and the others on a trunk Portgroup
Enter the following information and click on next/finish:
- Enter the credentials for the root, admin and CLI users
- Enter the hostname
- Enter the management network details
- Enter the DNS server with the Domain Search list
- Enter the NTP server
- Optional: select if you want to enable SSH access
Note: You need to deploy a NSX-T Edge node for every Edge Service gateway. When you have your Edge Service Gateway configured with HA, you will need to deploy 2 NSX-T Edge nodes so that it can be configured in active-passive mode.
Verify NSX-T Edge connectivity
Note: The data plane service does not start by default, because of that we need to login in to the CLI with admin credentials.
Once logged in to the CLI, lets verify the management network connectivity by entering the following command:
Also verify if you can ping the gateway, DNS servers and NTP server.
get interface eth0
Join NSX Edge Nodes with the Management Plane
Before we can join the Edge Nodes to the Management Plane, we need to retrieve the NSX-T manager API Thumbprint. To do so, we need to login to the NSX-T Manager with SSH and enter the following command:
get certificate api thumbprint
We can now use both the API Thumbprint to join the NSX-T Edge nodes to the management plane.
Log in to one of the NSX-T Edge node and use the following command:
join management-plane <Manager-IP> thumbprint <Manager-thumbprint> username admin
Once joined, verify the registered managers on the NSX-T Edge Node:
get managers
Let’s check the Edge Transport Nodes view in the NSX-T manager. Both Edge nodes are registered and having the configuration status: Pending
Note: Do not configure these Edge Nodes within the NSX-T Manager. The configuration will be done during the migration.
Change the global MTU setting
I have skipped this step because it was not applicable for my lab setup. But basically, when an Edge Services Gateway (ESG) is migrated it will get the default MTU value of 1500. You can change the MTU value for the interfaces after the migration or you can change the global MTU value before the migration.
Use this article on the NSX-T VMware docs website: link.
Prepare NSX-V environment
Make sure to check the following article at VMware to perform all the checks that are required: link
Start Migration
Enable the Migration Coordinator
To enable the migration coordinator in the NSX-T Manager, we need to SSH into the NSX-T manager appliance and execute the following command:
start service migration-coordinator
Import NSX-V Configuration
If you have like me, a supported Topology, you can click on Get Started and select Fixed Topology to start the NSX migration Wizard.
We now have to connect and authenticate to the NSX-V instance to retrieve all the current state configurations of the NSX-V environment.
During this phase the NSX-V configurations will be imported into the NSX-T Migration Coordinator. The most common problem during this phase may be that you do not have the correct number of edge nodes or not using the correct size type of edge nodes. In case of a failure, you can perform a rollback, correct the problem and try again.
You can click on View imported Topology to see the existing NSX-V topology.
In the Resolve Configuration phase, you need to check and verify all the issues. These are basically warnings like “NTP server configuration already present on NSXT” and you will get the option to skip this step or migrate the NTP server anyway.
I have selected Automated at the Choose Maintenance mode option for cluster issue. Automated is the recommended option when your environment is using VDS 7.0 or later.
With the automated migration mode, vCenter will migrate all VMs from the ESXI host that will be migrated to NSX-T (removing NSX-V VIB and installing NSX-T VIB).
Note: in Automated Maintenance mode, Migration Coordinator will not reconfigure VMs that are powered off. After migration, you need to manually configure these VMs before powering them on
The NSX-T migration Coordinator will now configure the NSX-V configurations in NSX-T. There is no downtime during this phase of the migration.
Configuration objects will be created in NSX-T and mapped to the NSX-V configuration objects.
Migrating Edges
We are now ready to perform the Edges migration. During this phase, the NSX-V Edges will be migrated to NSX-T. That means that the current NSX-V Edges will be powered off and the NSX-T Edges will be configured to take over the Edge services. The migration of the Edge nodes will take a few minutes
Note: Traffic will be disrupted during this phase, so schedule the Edge and Hosts migration tasks in one maintenance window.
Edge migration completed successfully, click on continue
Migrate ESXI hosts
The last step is to migrate all the ESXI hosts (NSX will be enabled on VDS 7.0 and later) and reconfigure the virtual machines from distributed portgroups to NSX-T logical segments.
This proces is fully automated with DRS and vMotion. because we have selected the Automated Maintenance Migration mode earlier.
Note: Traffic will be disrupted during this phase, so schedule the Edge and Hosts migration tasks in one maintenance window.
This step cannot be rolled back.
Final Words
We have completed all the steps in the Migration Coordinator to perform a migration from NSX-V to NSX-T (Fixed topology). In a later blog post, I will break down the steps of the user defined topology method where you can define your own NSX-T topology. This will require some manual preparations in the NSX-T environment. If you have any questions related to this topic, please do not hesitate to contact me.
good guide mate.
Thank you.
nice blog with detailed inputs. Thanks for sharing this.
Nice post mate.
Can you also confirm if you were able to make another blog for user defined topology ?
Thanks my friend. I did test the user defined topology migration, but have not created a blog about that yet. When I have time, I will retest it again and create a blog about it. In the meantime if you have any questions about the user defined topology migration, let me know.
Hi Mukesh,
I just published the user defined migration blog post.
You can read it over here: https://vkernel.nl/how-to-migrate-nsx-v-to-nsx-4-1-0-with-the-migration-coordinator-user-defined-topology.