We are thrilled to announce that the VMware NSX Migration for VMware Cloud Director 1.3.1 version is now generally available!
Following the 10.3.1 version of VMware Cloud Director, this 6th iteration of the NSX Migration for Cloud Director brings several additional migration capabilities:
The NSX Migration for VMware Cloud Director tool version 1.3.1 supports several new features.
- Migration to a target NSX-T provider VDC managed by a different vCenter Server instance
- Route advertisement enhancements for fully routed network topology
- DHCP static binding
- DHCP relay on the Edge Gateway
- Enhanced network pool support: port group backed network pool, network pool backed by multiple VDS, migration of organization VDC without network pool
- IPsec VPN enhancement: certificate based authentication, SHA-256 digest algorithm
- VMs using automated IP Pool address assignment will retain their IP address after the migration
- Updated assessment mode
Migration to a different vCenter
From 1.3.1 and onwards, the NSX Migration for Cloud Director tool migrates the workload VMs and other organization VDC objects to the same or a different vCenter Server managed by the same VMware Cloud Director instance.
This is particularly useful when the destination NSX-T cluster is greenfield (e.g., a new VMware Cloud Foundation instance).
Shared storage across NSX for vSphere and NSX-T backed vSphere clusters is preferred but not necessary.
Route Advertisement Enhancements
To provide a fully routed network topology in a NSX-T backed virtual data center, you can dedicate a Tier-0 or VRF gateway to a specific NSX-T edge gateway. Dedicating an external network to an edge gateway provides tenants with additional edge gateway services, such as route advertisement management and border gateway protocol (BGP) configuration.
Although we already supported BGP peer configuration for fully routed topologies, the NSX Migration for Cloud Director tool did not configured route advertisement between Tier-1 and Tier-0/VRF prior to version 1.3.1. This is now enhanced in 1.3.1 in the following way:
- BGP – When Route Redistribution is configured for BGP on the source NSX-V backed edge gateway, the migration tool will migrate all prefixes permitted by redistribution criteria that are either explicitly defined via Named IP Prefix, or implicitly via Allow learning from – Connected. Additionally, target gateway BGP IP Prefix Lists will be populated with specific IP Prefixes including allow/deny action. All such criteria are migrated into a single “
v-t migrated IP prefix list“.
- Static Routing – VMware Cloud Director does not support the configuration of static routes on NSX-T backed edge gateway, but they can be preconfigured on Tier-0/VRF by the provider prior to the migration. The migration tool will advertise all connected Org VDC networks from Tier-1 gateway to Tier-0/VRF if the flag
AdvertiseRoutedNetworksis set to
Truein the user input YAML file.
The VMware NSX Migration for Cloud Director 1.3.1 is now generally available and brings not only compatibility with VMware Cloud Director 10.3.1 but also additional features (DHCP binding / DHCP relay, routed network enhancements, network pools support enhancements, etc.).
Developed by the Cloud Infrastructure Business Group (CIBG), the VMware NSX Migration for VMware Cloud Director is THE solution you’re looking for to migrate NSX-V to NSX-T if you are running a VMware Cloud Director environment: it is an external automation tool that initiates and complete the migration process with minimum downtime.
We continue to improve the scenarios and the tooling to help our VMware Cloud Providers Partners to migrate VMware Cloud Director from NSX for vSphere to NSX-T. Whether you haven’t started thinking about the NSX-V to NSX-T migration yet, or are in the planning phase, the assessment mode is a key part of the process. So, don’t be shy, try it! 😉
This migration tool has a different release cycle than VMware Cloud Director, and we already started developing the next version.
You are encouraged to continue providing feedback to help us decide how the tool should evolve. We would love to hear about you, either here in the comments section, in social media (@woueb), or via your VMware representative.