VMware NSX-T Data Center Migration – Part 2 – NSX for vSphere (NSX-V) Preliminary Checks

Reading Time: 6 minutes

Welcome to the second article in the series detailing a migration of VMware NSX Data Center for vSphere (NSX-V) to NSX-T Data Center. In this article I focus on the preliminary checks to ensure the NSX-V environment is fit for migration.

In part 1 (VMware NSX-T Data Center Migration – Part 1 – Deploy Manager Appliance) I covered the process of deploying the NSX -T Data Center Manager Appliance, as well as a number of prerequisite tasks required to prepare the new NSX-T environment for the eventual migration (coming in part 3).

In this article I detail a number of preliminary checks within the NSX-V environment (including ESXi hosts, vSphere Distributed Switches, VXLAN configuration, VTEP, NSX Controllers, Edge Services Gateways, etc.) to ensure all is well prior to the migration process itself. Where any issues are identified, these must be resolved prior to the migration process.

System State

1. Confirm all NSX-V components are in a healthy state via the NSX Dashboard. Ensure any outstanding issues are resolved.

2. Confirm all all ESXi hosts are in a healthy operational state. Ensure any outstanding issues are resolved including disconnected hosts, hosts pending reboots, or hosts with pending tasks. Note: Hosts do not enter maintenance mode during migration.

3. Confirm publish status of Distributed Firewall and sync status of Service Composer (i.e. – the last publish operation should show success).

General NSX-V Configuration

1. Ensure VXLAN port is set to the default 4789. If this has been customised to utilise a different port, ensure this is re-configured before you attempt to migrate.

Controller Configuration

1. The NSX-T Migration Coordinator only supports NSX-V Transport Zones configured to utilise Unicast. Multicast or hybrid replication modes are not supported and will need re-configuring prior to the migration phase.

Host Configuration

1. vSphere DRS – Where needed, ensure vSphere DRS is set to Manual.

2. Distributed Firewall Filter – Set the Export Version of Distributed Firewall Filter on all Hosts to 1000. This must be set correctly on all hosts before you migrate them to NSX-T. To verify the export version and (where required) reconfigure, we will utilise the VMware Inter-networking Service Insertion Platform in conjunction with the I/O Control tool (vsipioctl).

• SSH onto each host.
• Retrieve the Distributed Firewall filter for the host by utilising vsipioctl:

vsipioctl getfilters | grep "Filter Name" | grep "sfw.2"

• Use the filter information to retrieve the export version for the host.

vsipioctl getexportversion -f {vNIC-ID}

• If the version is not 1000, set the export version by using the vsipioctl setexportversion command.

vsipioctl setexportversion -f {vNIC-ID} -e 1000

• Verify the export version is updated.

vsipioctl getexportversion -f {vNIC-ID}

3. vSphere Distributed Switches – An NSX-V environment can contain hosts that have NSX-V installed, but are not added to a vSphere Distributed Switch. NSX-T cannot. As such, you must ensure that all hosts are added to a vSphere Distributed Switch before you can migrate them. If you begin the migration task before making this change you will need to restart the migration to import the updated configuration.

Once the migration process is complete, you can remove the hosts from the distributed switch. If you opted to add the hosts to a new distributed switch that you are not using for other purposes, you can simply delete the distributed switch.

4. Distributed Firewall – Confirm Distributed Firewall is enabled for each cluster you which to migration to NSX-T. You can view the enabled status by browsing to Installation & Upgrade > Host Preparation. Any cluster with the Distributed Firewall enabled before migration is also enabled post-migration to NSX-T. Ensure you understand the impact of enabling  the Distributed Firewall and change the Distributed Firewall configuration accordingly where required.

5. VXLAN Tunnel Endpoint (VTEP) – Verify all hosts have only one VTEP interface. Check each host by browsing to Hosts and Clusters > Host > Configure > VMKernel adapters, and ensure there is only one interface with a vxlan TCP/IP stack per host. Note, migrating hosts with multiple VTEPs is not supported.

Edge Services Gateway Configuration

1. Routing Protocol – Edge Services Gateways must use BGP for north-bound routing. If OSPF is used, you must reconfigure to use BGP before you start the migration.

2. IPSec VPN – NSX-V supports policy-based IPSec VPN sessions where the local and peer subnets of two or more sessions overlap with each other. This behaviour is not supported on NSX-T, and must be reconfigured to ensure there is no overlap before you start the migration. If this configuration issue is not resolved, the Migrate Configuration task will fail.

3. Load Balancing (One-Armed/Proxy Mode) – If you have an Edge Services Gateway performing one-armed load balancer functions, you must make the following changes before you import the configuration:

• If the Edge Services Gateway has a management interface configured, you must delete it before migration. If you do not, the Migrate Configuration task will fail.
• 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 and is generally seen as a best practice when migrating.

4. Topology – Verify that the Edge Services Gateways which are part of the NSX-V environment are correctly attached to the rest of the environment. 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.

5. MTU Settings – Customised MTU settings in the Edge Services Gateways routing interfaces are not migrated to NSX-T. Any logical router interfaces created in NSX-T use the global default MTU setting (1500). If you want to ensure that all logical router interfaces have a larger MTU, you can change the global default MTU setting.

• Retrieve the current global default configuration.

GET /api/v1/global-configs/RoutingGlobalConfig

• Modify the MTU global default (logical_uplink_mtu).

PUT /api/v1/global-configs/RoutingGlobalConfig

• Run a final GET to confirm the successful global default change.

In part 3 I perform the final step of migrating NSX-V to NSX-T, however, it is important that all preliminary steps detailed in this article are reviewed prior to diving straight into the migration.

Further Information

• VMware Docs – Prepare NSX Data Center for vSphere Environment for Migration
• VMware Docs – Configure Hosts Not Attached to vSphere Distributed Switches
• VMware Docs – Configure Export Version of Distributed Firewall Filter on Hosts