In this migration mode, you migrate the Distributed Firewall (DFW) configuration from NSX-V to NSX-T. If you have Identity Firewall (IDFW) configured, it will also be migrated.
For more information about migrating IDFW, see Migrating Identity Firewall (End-to-End and Lift-and-Shift).
- 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.
Depending on the DFW configuration, there are two ways to migrate the workload VMs after you migrate the DFW configuration. If "Applied To" is not configured in any of the DFW rules (this means that "Applied To" is set to "DFW"), you can use the vSphere Client to migrate the workload VMs (follow the procedure Migrate Workload VMs (Simple Case)). Otherwise, you must use a script to migrate the VMs (follow the procedures Create VM Groups for Workload Migration and Migrate Workload VMs (Complex Case)).
Migration of a single site NSX-V 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-V 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.
- Migrate only the existing Distributed Firewall configuration from NSX-V to NSX-T.
- Use the layer-2 Edge bridge and vSphere vMotion to migrate workload VMs from NSX-V to NSX-T.
To extend the layer-2 networks, you can use the NSX-T native Edge bridge.
Prerequisites for DFW-Only Migration
- A new NSX-T environment is prepared for this migration.
- No user-defined DFW rules exist in NSX-T 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.
- 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.
- In DFW-only migration mode, 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 Security Tags are migrated 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.
- The automated migration of the DFW configurations supports workload VMs that are attached to NSX-V logical switches. These VMs will be migrated to NSX-T overlay segments. Workload VMs in NSX-V that are attached to vSphere Distributed Virtual Port Groups are not automatically migrated to NSX Distributed Virtual Port Groups. As a workaround, you must create the NSX Distributed Virtual Port Groups manually and attach the workload VMs to them.
- DFW exclusion lists are not migrated. You need to re-create them on NSX-T after migration.
- Logical ports and switches that are created during migration are not deleted when the workload VMs are deleted. You must delete these ports and switches via the NSX Manager UI or the API.
- The default segments in NSX-T do no support DHCP servers and will result in the servers being down after migration.