In this migration, the migration coordinator migrates only the Distributed Firewall configuration from NSX Data Center for vSphere to NSX-T Data Center.
- User-defined Distributed Firewall (DFW) rules
- Grouping Objects
- IP Sets
- MAC Sets
- Security Groups
- Services and Service Groups
- Security Tags
- Security Policies created using Service Composer (only DFW rule configurations are migrated)
Guest Introspection service configuration and Network Introspection rule configurations in the Service Composer are not migrated.
Starting in NSX-T 3.1.1, migration of a single site NSX for vSphere deployment that contains an NSX Manager in primary mode, no secondary NSX Managers, and with universal objects on the primary site, is supported. Such a single site NSX for vSphere deployment is migrated to a single site NSX-T environment (non-federated) with only local objects.
For a detailed list of all the configurations that are supported for the migration of Distributed Firewall configuration, see the Detailed Feature Support for Migration Coordinator.
- Use the migration coordinator to migrate only the existing Distributed Firewall configuration from NSX-v to NSX-T Data Center.
- Use Layer 2 Edge bridge and vSphere vMotion to migrate workload VMs from NSX-v to NSX-T.
To extend Layer 2 networks, you can use the NSX-T native Edge bridge.
Prerequisites for DFW-Only Migration
- Supported software version requirements:
- NSX-v versions 6.4.4, 6.4.5, 6.4.6, 6.4.8 and later are supported.
- NSX-T Data Center version 3.1 or later.
NSX-T 3.1 supports this migration only with APIs. Migration with UI is available starting in NSX-T 3.1.1.
- A new NSX-T Data Center is prepared for this migration, and a Layer 2 bridge is pre-configured to extend the VXLAN Logical Switch in NSX-v to the overlay segment in NSX-T Data Center.
For detailed instructions, see:
- No user-defined DFW rules pre-exist in the destination NSX-T Data Center before this migration.
- All states in the System Overview pane of the NSX-v Dashboard are green.
- There are no unpublished changes for Distributed Firewall and Service Composer policies in the NSX-v environment.
- The export version of Distributed Firewall must be set to 1000 on the NSX-v hosts. You must verify the export version and update if necessary. For more information, see Configure Export Version of Distributed Firewall Filter on Hosts.
- All hosts in the NSX-managed cluster (NSX-v as well as NSX-T) must be connected to the same version of VDS and each host within the NSX-managed cluster must be a member of a single version of VDS.
- The lift and shift migration of DFW-only configuration does not involve migrating hosts from NSX-v to NSX-T. Therefore, it is not mandatory for the ESXi version that is used in your NSX-v environment to be supported by NSX-T.
- This Guide explains the DFW-only migration workflow in the migration coordinator UI. If you are using NSX-T 3.1, this migration is supported only with NSX-T APIs. To migrate using APIs, see the API calls that are explained in the Lift and Shift Migration Process section of the NSX Tech Zone article.
- In DFW-only migration mode of the migration coordinator, the firewall state (DVFilter) for existing connection sessions is maintained throughout the migration including vMotion. The firewall state is maintained regardless of whether the VMs are migrating within a single vCenter Server or across vCenter Servers. Also, the dynamic membership in the firewall rules is maintained after the migration coordinator migrates the Security Tags to the workload VMs.
- Objects that are created during the migration must not be updated or deleted before the migration is finished. However, you can create additional objects in NSX-T, if necessary.
- In NSX-T, DFW is enabled out of the box. All flows with sources and destinations as "any" in the DFW rules are allowed by default. When Distributed Firewall is enabled in the NSX-T environment, you cannot migrate the workload VMs again from NSX-T to NSX-v. Roll back of migrated workload VMs is not supported. The workaround is to add the workload VMs to the NSX-T Firewall Exclusion List, and then migrate the workload VMs back to NSX-v using vSphere vMotion.