Starting with NSX-T 3.2.1, you can migrate an NSX-V cross-vCenter environment to an NSX Federation environment in NSX-T.
A cross-vCenter environment in NSX-V is a multi-site deployment with one primary NSX-V and one or more secondary NSX-Vs. The primary NSX-V can have both universal objects and local objects, whereas the secondary NSX-V can have local objects only. The primary NSX-V can also act as a site because it can have both universal and local objects.
An NSX Federation deployment in NSX-T has one Global Manager (GM) and one or more Local Managers (LMs). The GM has global objects only and the LM's have local objects. The GM cannot act as a site because it cannot have local objects. Note that the term Local Manager refers to either a single NSX Manager or a cluster of NSX Managers for a site. In a production environment, each site should have a cluster of NSX Managers configured.
To migrate cross-vCenter to NSX Federation, you must initiate the migration from the Global Manager. From the manager UI, go to the screen and select Migrate NSX for vSphere and User-Defined Topology. You can then select either Complete Migration or Configuration Migration. If you choose Complete Migration, you will be doing an end-to-end migration. If you choose Configuration Migration, you will be doing a lift-and-shift migration.
Before the migration, you must configure NSX Federation in NSX-T. You must have one LM for each NSX-V site. For more information about configuring NSX Federation, see the section "Getting Started with NSX Federation" in the NSX-T Data Center Installation Guide.
In NSX-T 3.2.1, the NSX-V load balancer will not be migrated. Starting with NSX-T 3.2.2, The NSX-V load balancer will be migrated to an NSX-T load balancer.
Migrating VCF Workload Domains
- From VCF SDDC manager, deploy the necessary NSX-T infrastructure (Global Manager, Local Managers, Edge nodes) and create a layer-3 topology.
- Perform the pre-migration preparation tasks documented in this guide.
- From the Global Manager, migrate the NSX-V environment.
Migrating Universal Security Groups
In NSX-V, in an active-active environment, Universal Security Groups can contain the following objects only: security groups, IP sets, and MAC sets. You cannot configure dynamic membership or excluded objects. In an active-standby environment, Universal Security Groups can contain the following objects: security groups, IP sets, MAC sets, and universal security tags. You can also configure dynamic membership using the VM name.
Note that in a cross-vCenter environment, a dynamic membership condition, such as vm.name="abc", will only be applied to objects in a specific site and not to all the sites.
In NSX Federation, dynamic membership conditions in Global Groups will always be applied to all the sites. Therefore, when you migrate a Universal Security Group in NSX-V to a Global Group in NSX-T, the Global Group might have more members than the Universal Security Group.
Before the Universal Security Groups are migrated, the migration wizard will give you the option to either migrate or not migrate the Universal Security Groups.
Supported Limits
| Object | Limit |
|---|---|
| Sites | 4 |
| Hosts | 512 |
| Logical Switches (universal plus non-universal) | 8500 |
| Universal Distributed Firewall Rules | 24000 |
| Universal Firewall Sections | 500 |
| Universal Security Groups | 4000 |
| Universal IP Sets | 4000 |
| Universal IP Sets per Universal Security Group | 10 |
| Universal Security Tags | 750 |
