You must check the state of the NSX Data Center for vSphere environment and fix any problems found. Also, depending on your environment, you might need to change your NSX Data Center for vSphere configuration before you can migrate to NSX-T Data Center.
Check the following system states:
- Verify that the NSX for vSphere components are in a green state on the NSX Dashboard.
- Verify that all ESXi hosts are in an operational state. Address any problems with hosts including disconnected states. There must be no pending reboots or pending tasks for entering maintenance mode.
- Verify the publish status of Distributed Firewall and Service Composer to make sure that there are no unpublished changes.
- Back up the NSX for vSphere and vSphere environments. See "NSX Backup and Restore" in the NSX Administration Guide.
- The VXLAN port must be set to 4789. If your NSX for vSphere environment uses a different port, you must change it before you can migrate. See "Change VXLAN Port" in the NSX for vSphere NSX Administration Guide.
- Migration coordinator does not support NSX for vSphere transport zones using multicast or hybrid replication mode. An NSX Controller cluster is required if VXLAN is in use. VLAN-backed micro-segmentation topologies do not use VXLAN and so do not require an NSX Controller cluster.
On all host clusters in the NSX for vSphere environment, check these settings and update if needed:
- Set vSphere DRS accordingly.
Disable vSphere DRS if one of the following apply:
- In-Place migration mode will be used.
- Manual Maintenance migration mode will be used. See the note below.
- If Automated Maintenance migration mode will be used for migration and the vCenter Server version is 6.5 or 6.7.
Note: In the Manual Maintenance migration mode, if you decide to use vMotion for migrating VMs, you have the flexibility to either disable vSphere DRS, or use any one of the following vSphere DRS automation levels: Manual, Partially Automated, or Fully Automated.
Set vSphere DRS mode to Fully Automated if:
- Automated Maintenance migration mode will be used for migration and the vCenter Server version is 7.0.
- Disable vSphere High Availability.
- Set the export version of Distributed Firewall filter to 1000. See Configure Export Version of Distributed Firewall Filter on Hosts.
- Set vSphere DRS accordingly.
- If you have hosts that have NSX for vSphere installed, but are not added to a vSphere Distributed Switch, you must add them to distributed switches if you want to migrate them to NSX-T. See Configure Hosts Not Attached to vSphere Distributed Switches for more information.
- On each cluster that has NSX for vSphere installed, check whether Distributed Firewall is enabled. You can view the enabled status at .
If Distributed Firewall is enabled on any NSX for vSphere clusters before migration, Distributed Firewall is enabled on all clusters when they migrate to NSX-T. Determine the impact of enabling Distributed Firewall on all clusters and change the Distributed Firewall configuration if needed.
- Verify that all hosts have only one VTEP interface configured. Check each host in . Verify that there is only one interface with TCP/IP stack vxlan per host. Migrating hosts with multiple VTEPs is not supported.
Edge Services Gateway Configuration
- Edge Services Gateways must use BGP for northbound routing. If OSPF is used, you must reconfigure to use BGP before you start the migration.
- You might need to make changes to your NSX for vSphere route redistribution configuration before migration starts.
- Prefix filters configured at the redistribution level are not migrated. Add any filters you need as BGP filters in the Edge Service Gateway's BGP neighbor configuration.
- After migration, dynamically-learned routes between Distributed Logical Router and Edge Services Gateway are converted to static routes and all static routes are redistributed into BGP. If you need to filter any of these routes, before you start the migration configure BGP neighbor filters to deny these prefixes while permitting others.
- NSX for vSphere supports policy-based IPSec VPN sessions where the local and peer subnets of two or more sessions overlap with each other. This behavior is not supported on NSX-T. You must reconfigure the subnets so they do not overlap before you start the migration. If this configuration issue is not resolved, the Migrate Configuration step fails.
- If you have an Edge Services gateway performing one-armed load balancer function, you must change the following configurations if present before you import the configuration:
- If the Edge Services Gateway has an interface configured for management, you must delete it before migration. You can have only one connected interface on an Edge Services Gateway providing one-arm load balancer function. If it has more than one interface, the Migrate Configuration step fails.
- If the Edge Services Gateway firewall is disabled, and the default rule is set to deny, you must enable the firewall and change the default rule to accept. After migration the firewall is enabled on the tier-1 gateway, and the default rule accept takes effect. Changing the default rule to accept before migration prevents incoming traffic to the load balancer from being blocked.
- Verify that Edge Services Gateways are all connected correctly to the topology being migrated. If Edge Services Gateways are part of the NSX for vSphere environment, but are not correctly attached to the rest of the environment, they are not migrated.
For example, if an Edge Services Gateway is configured as a one-armed load balancer, but has one of the following configurations, it is not migrated:
- The Edge Services Gateway does not have an uplink interface connected to a logical switch.
- The Edge Services Gateway has an uplink interface connected to a logical switch, but the uplink IP address not does match the subnet associated with the distributed logical router that connects to the logical switch.
- If you plan to use vMotion to move VMs during the migration, disable all SpoofGuard policies in NSX Data Center for vSphere to prevent packet loss.
- Automated Maintenance mode uses DRS and vMotion to move VMs during migration.
- In Manual Maintenance mode, you can optionally use vMotion to move VMs during migration.
- In-Place migration mode does not use vMotion.