In this migration, north-south traffic is migrated from NSX-V Edge Services Gateways to NSX Edge nodes.

During the cutover, the uplinks on the NSX-V Distributed Logical Router are internally disconnected from the Transit Logical Switch to which the Edge Services Gateways are also connected. The uplinks on the NSX Edge nodes are brought online.

If your NSX-V environment has DHCP service configured on an Edge Services Gateway, the DHCP leases of the workload VMs are migrated to the NSX Edge during the Edge cutover. After the Edge cutover is finished, the workload VMs, which are still running on NSX-V prepared hosts, have the same DHCP leases as existed before the migration.

Remember that this migration mode does not migrate the existing NSX-V topology and logical configurations, such as routing, Edge firewall, distributed firewall, L3 networking services, and so on, to your new NSX environment. You must pre-configure the topology and the logical objects manually in your new NSX environment. Or migrate the logical configurations to NSX before starting the Edge cutover migration.

This migration mode does not do an in-place migration of your existing NSX-V hosts to NSX. You must migrate the existing hosts to NSX after the Edge cutover migration is finished.

Note: To use the Edge cutover migration mode, your NSX-V environment can be configured in any topology. In other words, the Edge cutover migration does not require the NSX-V topology to be mandatorily configured in any of the supported migration topologies that are explained in Fixed Topologies Supported for End-to-End Migration.

Prerequisites for Edge Cutover Migration

  • Supported software version requirements:
    • See the VMware Product Interoperability Matrices for required versions of vCenter Server and ESXi.
    • vSphere Distributed Switch versions 6.5.0, 6.6.0, and 7.0 are supported.
    • The NSX-V environment must match the NSX system requirements for ESXi, vCenter Server, and vSphere Distributed Switch.
  • A new NSX environment is deployed and configured for this migration.
    • Deploy NSX Manager appliances.

      In a production environment, add an NSX Manager cluster with three appliances. However, for migration purposes, a single NSX Manager appliance is adequate.

    • Deploy a vCenter Server appliance.

      The vCenter Server must be added as a compute manager in NSX. You can share the vCenter Server that is used in NSX-V or deploy another one in NSX.

    • Deploy the correct number of appropriately sized NSX Edge appliances to replace the NSX-V Edge Service Gateways to match it feature wise and performance wise. You can deploy the NSX Edge nodes on the existing NSX-V prepared hosts.
    • Join the Edge nodes to the management plane from the command line.
    • Configure NSX on the NSX Edge nodes.
    • Either create an NSX IP pool to use for the NSX Edge TEPs, or configure static IP addresses for the Edge TEPs.
    • Add tier-0 and tier-1 gateways depending on the requirements of your NSX network topology.
    • Create overlay segments in NSX with the same virtual network identifier (VNI) and subnet address as the Logical Switches in NSX-V.

      Use the NSX APIs to create the overlay segments. You cannot create overlay segments with the same VNI in the NSX Manager UI.

      You must create the segments with the SOURCE replication mode, and change the mode to MTEP only after the migration is done.

    • Create VLAN segments in NSX with the same VLAN IDs and subnet address as the VLAN Distributed Virtual Port Groups (DVPG) in NSX-V.
      Note: VLAN DVPG must be associated only with a VLAN ID. VLAN Trunk is not supported.
    • Connect the uplink interface of the tier-0 gateway to a transit VLAN segment.

      Configure dynamic route peering between tier-0 gateway and the north-facing physical routers.

    • Attach the NSX overlay segments to the downlinks of the tier-0 or tier-1 gateway depending on the requirements of your NSX topology.
    • For all Layer 3 services, such as Network Address Translation, Load Balancing, VPN, and so on, that are configured on the NSX-V Edge Services Gateway, pre-configure equivalent services on the tier-0 or tier-1 gateway of your NSX environment. Enable Route Advertisement and Layer 3 services on the tier-1 gateway. Enable Route Redistribution Status on the tier-0 gateway.
      Important: If a DHCP service is configured on your NSX-V Edge Services Gateway, pre-configure a Gateway DHCP service on the NSX overlay segment. For migrating DHCP leases, Edge cutover migration mode supports only Gateway DHCP service. Local DHCP server or Local DHCP relay is not supported.
    • The DPDK fast path uplink interfaces on the NSX edges (fp-eth0, fp-eth1, and fp-eth2) must be down.

      Use the NSX APIs to update the admin_status parameter of each DPDK fast path interface on the Edge transport node to down.

      For example, to change the admin_status parameter of fp-eth0 interface on the Edge transport node, run the following APIs:
      1. Retrieve the edge-id of the NSX Edge transport node:

        GET https://{nsxt-mgr-ip}/api/v1/transport-nodes

      2. Use the edge-id that you obtained in step 1 to retrieve the properties of the fp-eth0 network interface:

        GET https://{nsxt-mgr-ip}/api/v1/transport-nodes/{edge-id}/node/network/interfaces/fp-eth0

      3. Paste the full GET API response in a text editor and change the admin_status parameter to down.
      4. Paste the full edited API response in the request body of the PUT API:

        PUT https://{nsxt-mgr-ip}/api/v1/transport-nodes/{edge-id}/node/network/interfaces/fp-eth0

      For a detailed information about the parameters in these APIs, see the NSX API Guide.

    • You cannot map multiple tier-1 gateways without an edge cluster or a DR-only tier-1 gateway under a parent tier-0 gateway to DLRs. You also cannot map the parent tier-0 gateway to a DLR if you are mapping to a DR-only tier-1 gateway. If your topology requires mapping multiple DLRs, you must use an active-standby tier-1 gateway with an edge cluster assigned.