Updated on: 19 SEP 2019
Migration Coordinator | 28 FEB 2019
Check for additions and updates to these release notes.
What's in the Release NotesThe release notes cover the following topics:
The Migration Coordinator can be used to aid in the migration from NSX Data Center for vSphere to NSX-T Data Center. This feature is designed to migrate existing hosts without the use of vMotion. The Migration Coordinator supports migration of layer 2 networking, layer 3 networking, firewall, load balancing, and VPN.
There is no need for additional compute resources beyond the deployment of NSX-T Managers and Edge Nodes. Once the migration is complete a customer can uninstall NSX for vSphere and the associated Managers, Controllers and Edges. Please note that this migration does impact data plane traffic and is designed to be completed in a single change window.
Important: The migration from NSX Data Center for vSphere to NSX-T Data Center causes traffic outages during Edge and Host migration steps. You must complete the migration within a single maintenance window. Contact your VMware representative before attempting the migration.
Please carefully read the NSX-T Data Center Migration Coordinator Guide for more information about the migration process.
- Issue 2400965: Migration fails if VM vNIC is attached to VTEP port group
If a virtual machine has a vNIC connected to the port group used for the NSX for vSphere VTEP, migration will fail during the Migrate Hosts step.
Workaround: Connect the virtual machine vNIC to a port group that is not used for the VTEP and retry the migration.
- Issue 2384095: Migration of external syslog collector configuration to NSX-T fails
When a DNS name is used for the external syslog collector, and that name can't be resolved to an IP address, the migration of this configuration to NSX-T fails.
Workaround: You can either ensure that the DNS name resolves to an IP address, or reconfigure the syslog collector after the migration to NSX-T.
- Issue 2345649: Migration will fail if NSX for vSphere has any security groups with display names exceeding 245 characters
If any Security Group in NSX for vSphere has a display name with more than 245 characters, the migration process will fail in the Migrate Configuration step.
- Issue 2319981: Edge cutover fails in topology in one topology when more than one Edge Services Gateway-Distributed Logical Router pairs are present
If you migrate from the topology "Two Levels of ESG with L4-L7 Services on Second-Level ESG" and the environment contains more than one Edge Services Gateway-Distributed Logical Router pair, the Migrate Edges step fails and the system is in a partially migrated state. For topology descriptions, see Supported Topologies.
- Issue 2295435: Parallel cluster migration may fail due to platform rate-limiting of requests
Customer may experience migration failure with message saying Client 'admin' exceeded request rate of 100 per second
Workaround: Use serial cluster migration.
- Issue 2293445: If an Edge Services Gateway default route is specified via the default gateway section, it is not migrated
If the default route is specified via the default gateway section, it is not migrated, whereas default routes specified via the static route section are all migrated.
Workaround: Before migration, configure the default gateway as a static route. This can be done using the UI (NSX Edge > Routing > Static Routes) or API (
- Issue 2290906: In some circumstances, the Edge size recommended by migration coordinator is not large enough for load balancer services
Migration might fail if not enough Edge nodes are deployed for the configured load balancer services.
- Issue 2290812: After migration, approved/detected IPs on NSX for vSphere are converted into Manual bindings on NSX-T.
If these manual bindings are left, new IPs are not detected on this port.
Workaround: As a best practice, remove the manual bindings from all VM ports after migration is finished and validated. Before you delete a manual binding, go to Advanced Networking & Security > Switching > Ports and verify that the Auto Discovered Bindings list contains the correct IP address.
- Issue 2285219: Three minute North South traffic outage for workloads
Traffic from/to workloads to/from outside data center running on host undergoing migration sees more than three mins outage. Note that this is seen only for workloads on a host when that host undergoes migration from NSX Data Center for vSphere to NSX-T Data Center.
- Issue 2283688: Multicast traffic is not replicated on logical switches during the migration period.
There is an outage of multicast traffic on logical switches from the start of Edge migration to the end of Host migration.
- Issue 2283679: Cannot migrate DHCP server for logical switch with no VMs attached
If there are no VMs attached to a logical switch and DHCP is a configured service for this logical switch, the DHCP service is not migrated. If you create new VMs on this logical switch after migration, these new VMs cannot get a DHCP response.
Workaround: Create a new VM on the logical switch before migration. After that, DHCP service is migrated.
- Issue 2282738: Logical switches created during V2T migration have SOURCE based replication mod
All logical switches created from the migration coordinator have their replication mode set to SOURCE replication. This would lead to performance impacts since SOURCE replication mode for multicast is expensive.
Workaround: Manually go to each logical switch and change the replication mode to MTEP.
- Issue: 2281540 DHCP Relay only on DLR migration support
If you have DHCP Relay to external dhcp server configured on a Distributed Logical Router, this configuration cannot be migrated.
Newly created VMs using this DHCP Relay service would not be able to get dhcp response after migration.
Workaround: No workaround it if you want DHCP relay to external DHCP server serivce.