by In my previous post, I covered the end-to-end migration of VMware NSX for vSphere to NSX-T Data Center (VMware NSX from v4.0.0.1) via the Fixed Topology Option, however, in real life I don’t see this option utilised very often due to the limited number of supported topologies.
How then can we achieve the same in-place, end-to-end migration of unsupported topologies? This is where the User Defined Topology option comes into play, and it offers much greater flexibility by enabling customers to define/map their own logical routing topologies. This, of course, will require a design and, like the message I tried to impart in my previous post, this must be planned ahead of your proposed change/maintenance/migration window.
More in the NSX V2T Series…
- Part 1 – VMware NSX-T Migration Coordinator Report Export for Fixed Topology Migration
- Part 2 – VMware NSX for vSphere to NSX-T Migration – End-to-End Fixed Topology
- Part 3 – VMware NSX for vSphere to NSX-T Migration – End-to-End User-Defined Topology
Like the Fixed Topology option, the User Defined option will use your existing hardware, meaning no additional servers are required for the migration. The end-to-end migration will migrate the following:
- Logical networking and security configurations
- Edges
- Hosts
- Workload VMs
As mentioned earlier, the user-defined topology affords us much more flexibility in our migration options. In my test environment, I have multiple NSX-V ESGs, one of which is connected to a DLR, as well as multiple dynamic routing protocols in use. In practice, we can even map to VRFs.
In the below diagram, you will note the current NSX-V topology and how I will map this to NSX-T components.
IMPORTANT – As per my previous post, while the migration of your Edges and Hosts should take place during an approved maintenance/change window due to the expected workload outage, the Migration Coordinator and all steps prior to the migration of edges and hosts can be run ahead of time and with zero impact to your production workloads. It is, therefore, recommended to run the Migration Coordinator ahead of time to ensure all issues/recommendations/configurable input (Edge TEP IP Pool, Edge TEP VLAN, uplink IP addresses, etc.) are reviewed and prepared in readiness for the migration. When you are ready to initiate the migration itself, it is recommended to roll back fully before proceeding.
Prerequisites
- Ensure NSX-V is in a stable state
- Ensure NSX-V backups are healthy and a recent backup has been taken
- Ensure NSX-V VXLAN port is set to 4789 (default)
- Ensure the export version of the NSX-V DFW is set to 1000 (default)
- VDS 7.0 or higher required
Deploy NSX Manager Appliance
Like my previous post, we must ensure all prerequisites are in place in order to support migration activities. As we are migrating via the User Defined Topology, several new prerequisites must be configured ahead of the migration.
- Deploy a single NSX Manager Appliance
- Add license
- Add a Compute Manager
- Change the Global MTU Setting (where required)
- Create an IP Pool for Edge Tunnel End Points (TEPs)
- Create NSX-T VLAN-backed Segments for Tier-0 uplink interfaces
- Create NSX-T Edge Clusters in readiness for later steps
- Deploy NSX Edge Nodes via OVA
- Identify NSX Manager Thumbprint
- get certificate api thumbprint
- Add NSX Edge Nodes to Management Plane
- join management-plane <NSX-Manager-IP-Address> thumbprint <NSX-Manager-Thumbprint> username admin
- Start Migration Coordinator service
- start service migration-coordinator
Import Configuration
Those who have read my previous post will recognise this initial section to import the NSX for vSphere configuration. At this stage, it is important that no changes to either NSX-V or NSX-T are made. If any changes are made that need to be captured/utilised during the Migration Coordinator, you will need to roll back.
Note – Rollbacks can be initiated at any time prior to the migration of edges. Should you make any mistake, or if you forget to create any of the prerequisites (Edge TEP IP Pool, for example), simply roll back and start again.
Browse to System > Lifecycle Management > Migrate, and select NSX for vSphere > User Defined Topology. When ready, click Next.
Click Next.
Select Complete Migration and click Select NSX.
Enter both your vCenter Server and NSX for vSphere credentials, and click Authenticate.
When ready, click Next.
Click Start to check prerequisites, import vCenter and NSX for vSphere configuration, and to begin translation of the imported configuration.
When prompted, click Continue.
If successful, click Continue. If unsuccessful, review all errors and work to resolve.
Translate Configuration – Layer 2
When ready, click Start to begin the translation of the imported L2 configuration from NSX for vSphere.
Resolve Configuration – Layer 2
This is the most important stage of the migration process. Ensure all issues identified by the Migration Coordinator are resolved, configured or skipped appropriately and that all are read and understood. As mentioned previously, these issues/queries can be viewed ahead of time, as no changes/migrations will take place until the Migrate Edges stage.
In this stage, you will be prompted to provide, among others, the name of your Edge TEP IP Pool, Edge TEP VLAN, a Tier-0 Gateway uplink interface IP address, etc., all of which should (where possible) be allocated ahead of time. Again, use this information before your change/maintenance window to ensure all of the required information has been set up in advance of the migration.
Work through the items one by one, clicking Submit if you need to save your progress or take a break.
When all items are resolved/green, click Continue.
Migrate Configuration – Layer 2
This stage will see NSX for vSphere components migrated into NSX-T Data Center. Note, all workloads will continue to operate from NSX for vSphere; this stage will merely create the new constructs in readiness for the later migrations.
When ready, click Start to begin the configuration migration.
When prompted, click Migrate.
Once complete, note the object mappings. When ready, click Continue.
Check Realization – Layer 2
When ready, click Start to initiate the validation of migration L2 configurations from NSX for vSphere.
When ready, click Next.
PAUSE – Tier-0 and Tier-1 Gateway Creation and Configuration
At this stage, you will note that all edges have been assigned to the relevant edge clusters as per your earlier submission in the Resolve Configuration Layer 2 stage. Ensure all Edge TN are assigned to the correct Edge Cluster in readiness for ESG/DLR to T0/T1 mappings in the next stage, Define Topology.
Likewise, all Tier-0/Tier-1 Gateway(s) should now be created (including uplink interfaces, dynamic routing, route redistribution, etc.), all of which should be assigned to the appropriate edge cluster. Also, validate the physical fabric to ensure dynamic routing has converged, BGP sessions are established and/or OSPF neighbourships are FULL.
After creating and configuring my Tier-0 Gateways, the below screenshots validate full convergence.
Define Topology
Provide the relevant ESG/DLR to T0/T1 mappings and, when ready, click Continue.
Translate Configuration L3, L4-L7 Services
When ready, click Start to begin the translation of the L3 and L4-L7 services’ configuration from NSX for vSphere.
If successful, click Continue. If unsuccessful, review all errors and work to resolve.
Resolve Configuration L3, L4-L7 Services
Much like the earlier Resolve Configuration Layer 2 stage, we will be prompted to resolve/provide information/skip L3, L4-L7 services. This might include items such as the configuration of ESG/DLR downlinks (those internal links which map to Logical Switches), RBAC, appliance management and backups, etc.
Again, ensure all issues identified by the Migration Coordinator are resolved, configured or skipped appropriately. As mentioned previously, these items can/should be reviewed ahead of time, as no changes/migrations will take place until the Migrate Edges stage.
Work through the items one by one, clicking Submit if you need to save your progress or take a break.
When all items are resolved/green, click Continue.
Migrate Configuration L3, L4-L7 Services
This stage will see NSX for vSphere components migrated into NSX-T Data Center. Note, all workloads will continue to operate from NSX for vSphere; this stage will merely create the new constructs in readiness for the later migrations.
When ready, click Start to begin the configuration migration.
When prompted, click Migrate.
Once complete, note the object mappings. When ready, click Continue.
Check Realization L3, L4-L7 Services
When ready, click Start to check the realisation of the migrated L3 and L4-L7 services’ configuration from NSX for vSphere.
If successful, click Continue. If unsuccessful, review all errors and work to resolve.
Migrate Edges
Until now, all we have done is provide information and configurations which have been used to create numerous NSX-T constructs. No migrations of edges, hosts, or workloads have taken place. Until now.
Once the edge migration is initiated, our workloads will experience a drop in connectivity. As such, uplink interfaces on our NSX for vSphere ESGs will drop. Note, due to this, it is recommended to perform edge and host migration in one maintenance window.
When ready, click Start.
When prompted, click Migrate.
Monitor the migration process and, when successful, click Continue.
During the edge migration, we experienced expected packet loss. The below screenshot displays continuous ICMP to a VM (10.0.100.110.11) housed on a NSX-V Logical Switch.
Likewise, after the successful edge migration, connectivity to the same VM is now routed via the new T0 (10.0.61.12) and T1 (100.64.152.1 = T0-T1 internal transit network) gateways.
Lastly, note dynamic routing for both of the NSX-V ESGs drops. The below screenshot shows BGP peering for ESG-01 (10.0.61.11) drops, and ESG-02 (10.0.61.13)’s OSPF neighbourship is removed, leaving T0-GW-02 as the only OSPF neighbour.
Host Migration
Our final task of the migration process is to migrate the hosts themselves. This will see all NSX-V VIBs removed and replaced with NSX-T, NSX switch configuration, etc.
When ready, click Start.
When prompted, click Migrate.
Click the relevant Host Group (vSphere Cluster) to monitor progress. In the below screenshots, you will note pre-transport node staging for specific hosts…
…as well as the removal of NSX-V VIBs.
During the process, you will note host preparation via System > Configuration > Fabric > Nodes > Host Transport Nodes.
As each host is completed, note the application of a Host TEP IP address (the IP Pool for which utilises your NSX-V configured IP range), and the Node Status should change to Up.
If you were to browse to NSX-V, not the communication channels drop as each host is migrated to NSX-T.
The same activities will now be processed on each of the remaining hosts.
Once all hosts have successfully migrated, click Finish.
When prompted, click Finish.
Validation
Following the successful migration of your NSX-V configuration, edges and hosts, routing and workload validation should now be actioned. BGP/OSPF peering should be confirmed as up, workload connectivity, etc., as well as ensuring your VMs are now housed on the Overlay/VLAN-backed NSX-T Segments.
Likewise, in the below screenshot, you’ll note a before/after of the routing to a workload VM (10.100.110.11) has switched from my ESG to DLR (10.0.61.11 > 200.200.200.11) to my T0 (10.0.61.12).
Post-Migration Tasks
Finally, all that is left is a few clean-up tasks, none of which will be covered in this article but are documented in detail via Post-Migration Tasks (vmware.com):
In Summary
In this article, I demonstrated the process of utilising the NSX-T Migration Coordinator to migrate an NSX-V environment to NSX-T. Specifically, I migrated end-to-end via the User-Defined Topology option. As discussed early on in the article, where you have a topology that does not match one of the fixed topologies supported for migration, the User-Defined option can be very flexible, and this is something which can also be utilised to map to VRFs.
IMPORTANT – As per my previous post, while the migration of your Edges and Hosts should take place during an approved maintenance/change window due to the expected workload outage, the Migration Coordinator and all steps prior to the migration of edges and hosts can be run ahead of time and with zero impact to your production workloads. It is, therefore, recommended to run the Migration Coordinator ahead of time to ensure all issues/recommendations/configurable input (Edge TEP IP Pool, Edge TEP VLAN, uplink IP addresses, etc.) are reviewed and prepared in readiness for the migration. When you are ready to initiate the migration itself, it is recommended to roll back fully before proceeding.
As NSX for vSphere went end of life in January 2022, the need to migrate to a supported platform is paramount. If you have any queries regarding the migration of NSX for vSphere to NSX-T Data Center (now VMware NSX from 4.0.0.1 onwards), please don’t hesitate to reach out directly.
More in the NSX V2T Series…
- Part 1 – VMware NSX-T Migration Coordinator Report Export for Fixed Topology Migration
- Part 2 – VMware NSX for vSphere to NSX-T Migration – End-to-End Fixed Topology
- Part 3 – VMware NSX for vSphere to NSX-T Migration – End-to-End User-Defined Topol
Leave a Reply