by In a previous post focusing on the VMware NSX Migration Coordinator (VMware NSX for vSphere to NSX-T Migration – End-to-End User Defined Topology), I detailed the end-to-end process required to migrate VMware NSX Data Center for vSphere (NSX-V) to VMware NSX-T Data Center (now simply VMware NSX as of 4.x) and, more specifically, the ‘User Defined’ option, which allows customers to map NSX-V Edge Services Gateways (ESGs) and Distributed Logical Routers (DLRs) to NSX-T components (e.g., Tier-0 or Tier-1 Gateways). To perform this mapping, customers can either a) upload a pre-defined JSON file or b) use the NSX UI to select the appropriate Tier-0/Tier-1 Gateway via drop-down menus.
The previous post utilised VMware NSX Data Center for vSphere 6.4.13 and VMware NSX-T Data Center 3.2.1, however, labbing this in readiness for an upcoming customer engagement required VMware NSX Data Center for vSphere 6.4.14 and VMware NSX (formerly NSX-T) 4.0.1.1; herein lies the identification of a possible bug when using the UI to map ESGs/DLRs to Tier-0/Tier-1 Gateways.
First, let’s revisit the proposed user-defined topology. I want to map the below NSX-V ESGs/DLRs to the corresponding NSX Tier-0/Tier-1 Gateways. Specifically:
| NSX-V Name | NSX Name |
| NSX-ESG-01 (edge-1) | t0-gw-01 |
| NSX-DLR-01 (edge-5) | t0-gw-01 |
| NSX-ESG-01 (edge-4) | t0-gw-02 |
Likewise, a visual for the migration and mappings are defined below:
Per my previous post, I used the NSX UI to define the mappings (see screenshot below).
However, this time around, I hit a snag. On the next tab (Translate Configuration L3, L4-L7 services), I was now presented with an error message:
Specifically:
Config translation failed [Reason: [topology_plugin] Can not proceed with migration: Invalid NSX V Manager IP address <NSX-V-MANAGER-FQDN> is provided for mapping [{v_edges':['edge-1'], 'policy_gateway_name': 't0-gw-01', 'policy_gateway_path': '/infra/tier-0s/t0-gw-01'},{v_edges':['edge-4'], 'policy_gateway_name': 't0-gw-02', 'policy_gateway_path': '/infra/tier-0s/t0-gw-02'},{v_edges':['edge-5'], 'policy_gateway_name': 't1-gw-01', 'policy_gateway_path': '/infra/tier-1s/t1-gw-01'}]]This is validated by checking the /var/logs/migration-coordinator/migration-coordinator.log:
The alert itself is a little misleading as, at first glance, the issue appears to be an ‘Invalid NSX V Manager IP address <NSX-V-MANAGER-FQDN> is provided for mapping’, and all logs reference the same description, adding little to the troubleshooting effort.
JSON to the Rescue
By performing a rollback, I was able to switch to the JSON file option. This worked successfully; by using the below JSON file to configure the mappings, I could upload the JSON file in preference of the NSX UI and progressed successfully with the next steps of my migration. The mappings in the JSON file mirrored the mappings via UI.
[
{
"name":"nsxv-to-nsxt-mapping",
"v_edges_to_policy_gateways_mappings":[
{
"v_edges":[
"edge-1"
],
"policy_gateway_name": "t0-gw-01",
"policy_gateway_path": "/infra/tier-0s/t0-gw-01"
},
{
"v_edges":[
"edge-5"
],
"policy_gateway_name": "t1-gw-01",
"policy_gateway_path": "/infra/tier-1s/t1-gw-01"
},
{
"v_edges":[
"edge-4"
],
"policy_gateway_name": "t0-gw-02",
"policy_gateway_path": "/infra/tier-0s/t0-gw-02"
}
]
}
]
Root Cause
EDIT – 2023-04-04 – After troubleshooting and several additional attempts, defining the NSX-V Manager via FQDN (instead of the IP address) seemed to be the culprit. When running each additional migration, not once did I experience the error when using an IP address, whereas I experienced the issue every time I used the FQDN.
Was this a bug in my environment only? Possibly. Will this occur in other environments? Possibly. Should you experience the same error after having specified the NSX-V Manager via FQDN, mapping the configuration via JSON file will certainly aid you, as rolling back to the very start might not be feasible. Or, of course, you can simply specific the NSX-V Manager via IP address from the very beginning.
Leave a Reply