You must check the NSX-v environment and fix any problems found. Also, depending on your environment, you might need to change your NSX-v configuration before you can migrate to NSX-T.

System State

Check the following system states:

  • If your environment is vSphere 7.0 or later, upgrade the VDS to 7.0 or later.
  • Verify that the NSX-v 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 that no NSX-v upgrades are in progress.
  • Verify the publish status of Distributed Firewall and Service Composer to make sure that there are no unpublished changes.
  • You can have vSphere High Availability (HA) enabled if the NSX-v environment has VDS 7.0 or later.

    Note: HA is not supported for previous versions of VDS This is because if the NSX-v environment has VDS 6.5 or 6.7, and the vmkernel ports (vmk's) are attached to VDSes, during an in-place migration, the hosts and VMs may lose network connectivity for a period of time long enough to trigger HA. The HA mechanism will try to power off, migrate and restart VMs. This might fail because the NSX-v environment is being migrated to NSX-T. As a result, after the migration, VMs might remain in a powered-off state or have no network connectivity if powered on. To avoid this situation, disable HA or attach the management vmk to a VSS before starting the migration.

General Configuration

  • Back up the NSX-v and vSphere environments. See "NSX Backup and Restore" in the NSX Administration Guide.
  • The VXLAN port must be set to 4789. If your NSX-v environment uses a different port, you must change it before you can migrate. See "Change VXLAN Port" in the NSX-v NSX Administration Guide.

Controller Configuration

  • Migration coordinator does not support NSX-v 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.

Host Configuration

  • On all host clusters in the NSX-v 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. In this mode hosts are not put in maintenance mode during migration and VMs will experience a network outage and network storage outage during the migration. This mode is only available if the environment is vSphere 6.x (VDS will be migrated to N-VDS).
      • Manual Maintenance migration mode will be used. If you decide to use vMotion for migrating VMs, you can disable vSphere DRS, or set the vSphere DRS automation level to Manual, Partially Automated, or Fully Automated.
      • If Automated Maintenance migration mode will be used for migration and the vCenter Server version is 6.5 or 6.7.

      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.

      Note that in Automated Maintenance mode, Migration Coordinator will not reconfigure VMs that are powered off. After migration, you need to manually configure these VMs before powering them on.

    • Set the export version of Distributed Firewall filter to 1000. See Configure Export Version of Distributed Firewall Filter on Hosts.
  • To migrate Network Introspection service rules, use the Maintenance host migration mode. In-Place migration mode is not supported.
  • If you have hosts that have NSX-v 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-v installed, check whether Distributed Firewall is enabled. You can view the enabled status at Installation & Upgrade > Host Preparation.

    If Distributed Firewall is enabled on any NSX-v 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.

Edge Services Gateway Configuration

  • You might need to make changes to your NSX-v 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-v 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-v 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.

Security Configuration

  • 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.

Security Group Configuration

If existing Security Policies contain Guest Introspection service rules that are applied to Security Groups with static VM members or dynamic members other than VMs, do these steps:
  1. Create new Security Groups with VMs only in the dynamic membership criteria. Make sure that the dynamic membership criteria produces the same effective VM members as your original Security Groups.
  2. Before running the migration coordinator, update the existing Security Policies to apply the new Security Groups to the Guest Introspection service rules.

    If you prefer not to update your existing Security Policies before migration, you can still keep the new Security Groups ready with the correct dynamic membership criteria in your NSX-v environment. During the Resolve Configuration step of the migration process, when the migration coordinator shows warning messages and prompts you to provide alternative Security Groups, select the new Security Groups and proceed with the migration.

Service Composer Synchronization

Ensure that the Service Composer is in sync with Distributed Firewall before you start the migration coordinator. A manual synchronization ensures that if you make any last-minute changes in the policy configuration before starting the migration, these changes are applied to the Security Policies that are created using Security Composer too. For example, you edit the name of the Security Group that is used in a firewall rule before starting the migration.

To verify whether the Service Composer status is in sync, do these steps:
  1. In the vSphere Client, navigate to Networking and Security > Security > Service Composer.
  2. Click the Security Policies tab.
  3. Verify that the Sync Status is In Sync. If it is not in sync, click Synchronize.

As a preferred practice, always click the Synchronize button before starting the migration coordinator even when the sync status is green. Do this manual synchronization regardless of whether you performed any last-minute changes in the policy configuration.

During migration, if the Service Composer status is not in sync, the Resolve Configuration step shows a warning. You can skip the migration of the Security Policies created using the Service Composer by skipping the relevant Distributed Firewall sections. Alternatively, you can cancel the migration, get the Service Composer in sync with Distributed Firewall, and restart the migration.