Check your NSX-V environment before starting an end-to-end migration.

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

  • NSX-V transport zones using multicast or hybrid replication mode are not supported for migration. 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.
      • Automated Maintenance migration mode will be used and the VDS version is 6.5 or 6.7.

      Set vSphere DRS mode to Fully Automated if:

      • Automated Maintenance migration mode will be used and the VDS 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.

  • 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. 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. 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.
    • Redistribution filters are not migrated. For BGP, filters can be moved to the BGP neighbor level.
    • After migration, dynamically learned routes between Distributed Logical Router and Edge Services Gateway are converted to static routes and all static routes are redistributed in BGP or OSPF. If you need to filter any of these routes, you can configure them at the BGP neighbor level or manually configure the redistribution rules on NSX after the configuration migration is completed and before cutover. Note that if you roll back, the manual configuration of redistribution rules will also be removed.
    • The default MTU setting is 1500 on NSX. If you have non-default MTU setting requirements, you can change the setting. See Change the Global MTU Setting.
  • 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. 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-V 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 starting the migration, 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 the migration, you can still keep the new Security Groups ready with the correct dynamic membership criteria in your NSX-V environment. In the Resolve Configuration step of the migration process, you will be prompted to provide alternative Security Groups.

Service Composer Synchronization

Ensure that the Service Composer is in sync with Distributed Firewall before you start the migration. 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 best practice, always click the Synchronize button before starting the migration 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 roll back the migration, get the Service Composer in sync with Distributed Firewall, and restart the migration.