VMware NSX Migration for VMware Cloud Director 1.4.1 | 10 JAN 2023 Check for additions and updates to these release notes. |
VMware NSX Migration for VMware Cloud Director 1.4.1 | 10 JAN 2023 Check for additions and updates to these release notes. |
The NSX Migration for VMware Cloud Director tool version 1.4.1 supports several new features:
External Networks directly connected to NSX-T Tier-1 Gateway: VMware Cloud Director version 10.4.1 or higher allows connecting an NSX-T overlay or VLAN-backed external network to a gateway via service interface connection. VLAN segment-backed external network can be connected to only one edge gateway (a single network can be connected to a single edge node per VLAN Id). The migration tool will create necessary static routes when the default gateway is towards the external network that is directly connected to the edge gateway.
Support for Transparent Load Balancing: You can migrate edge gateways with load balancer service having transparent pools configured with VMware Cloud Director version 10.4.1.
Support for Load Balancer VIP (IPv4) from Org VDC Network Subnet: You can migrate edge gateways with load balancer virtual service VIP and load balancer pools using IPv4 address from Org VDC network subnet with VMware Cloud Director version 10.4.1.
Edge Gateway Assessment Reports: The migration tool in addition to the existing Assessment and Summary reports will also create an Edge Gateway detailed report and a Load Balancer detailed report when they run in V2T assessment mode. These reports contain a detailed analysis of edge gateways and load balancer services enlisting the Objects (Name/ID) causing possible blockage of migration.
NAT service Enhancement: From VMware Cloud Director version 10.4.1 onwards, Org VDC networks on which NAT rules are applied will be migrated as Non-Distributed networks. When such NAT rules are created on the NSX-T edge gateway, they will be applied to their respective Non-Distributed Org VDC network interface as per their NSX-V counterpart. NAT rules will also be applied to segment-backed external network in case of NSX-T edge gateway uplink connected to it via the service interface.
Firewall Service Enhancement: From VMware Cloud Director version 10.4.1 onwards, firewall rules on NSX-T backed edge gateway will be applied to the Org VDC network to which they are scoped. The scope of firewall rules will be determined from the NAT rule using the firewall rule IP address. In case if no NAT rule using the firewall rule IP address, then the firewall rule will be applied to all edge gateway interfaces.
Enhancement to reduce downtime during migration and rollback: Modified the workflow of migration and rollback to reduce downtime during N-S network switchover.
Workaround to fix network connectivity loss issue after NSX-T to NSX-V vMotion: For NSX-T to NSX-V migration, when migrating a workload VM back to NSX-V, the network connectivity might not work because the distributed firewall filter in NSX-T is always higher than in NSX-V. The workaround is to place the workload VM in the NSX-T exclusion list before vMotion. This workaround is included as part of the rollback with the current release of the migration tool. For more information, see Migrate Workload VMs.
Rollback Fails at ‘Reset the target external network’
Step:
[vcdOperations]:[resetTargetExternalNetwork]:3911 [INFO] [VDC-demo]| Rollback:Reset the target external network
Exception:
Failed to reset the target external network 'external-network-name' to its initial state: [ xx-xx-xx-xx-xx] The provided list 'ipRanges.values' should have at least one item in it.
Reason: During rollback, the migration tool removes the IP address/s used by the target edge gateway from the target external network. If the target external network has no spare IP in its static IP Pool apart from the ones used by target edge gateway/s, then the migration tool will not be able to remove the IPs as a minimum of one IP should be present in every subnet of an external network.
Workaround: Add additional IP(s) to the static IP pool of the target external network and run the rollback.
Resolution: set the EmptyIPPoolOverride field as True in the input YAML file.
Cleanup Fails at ‘Updating the source External network’
Step:
[vcdNSXMigratorCleanup]:[run]:3542 [INFO] [VDC-demo]| Updating the source External network.
Exception:
Failed to update source external network ‘external-network-name' : [ xx-xx-xx-xx-xx] The provided list 'ipRanges.values' should have at least one item in it.
Reason: During cleanup, the migration tool removes the IP address/s used by the source edge gateway from the source external network. If the source external network has no spare IP in its static IP Pool apart from the ones used by source edge gateway/s, then the migration tool will not be able to remove the IPs as a minimum of one IP should be present in every subnet of an external network.
Workaround: IP/s need to be cleaned manually from the static IP Pool of the source external network in case of failure.
Resolution: set the EmptyIPPoolOverride field as True in the input YAML file.
VM loses N-S traffic after rollback
After rollback is completed, VMs may lose N-S connectivity. VM loses N-S traffic following vMotion to an NSX for vSphere host after NSX-v to NSX-T Edge migration cutover was done.
Fixed in NSX-T 3.1.3.3 (for more details, see NSX-T Release Notes).
VMs connected to distributed Org VDC networks lose network connectivity after N-S network switchover
VMs connected to distributed Org VDC networks lose network connectivity after N-S network switchover and bridging does not work.
Workaround: Ensure that the MAC Address of the NSX-T Virtual Distributed Router is using a different MAC address than the NSX-V distributed logical router. For more details, see NSX-T documentation.
Migration of VM with disconnected NIC fails
Migration of VM fails if a network is assigned to the VM NIC, but it's in a disconnected state (by unchecking the "Connected" box in VMware Cloud Director Tenant Portal).
Workaround: Set the Network value for the VM to "None".
Resolution: The issue is fixed in VMware Cloud Director 10.3.3.2 and 10.4 releases.
Migration of VM with placement policy fails
The operation failed because no suitable resource was found. Out of 1 candidate hubs: 1 hubs eliminated because: Only contains rejected VM Groups(s): [[VM+Group1], [VM+group1]] Rejected hubs: resgroup-4416 PlacementException NO_FEASIBLE_PLACEMENT_SOLUTION
Workaround: Make sure that VM groups backing the source and target placement policy are identically named.
Routed Org VDC network with non-distributed enabled creation fails to connect the interface of the edge gateway
Creation of routed Org VDC network with non-distributing routing enabled on it fails with “Failed to connect the interface of edge gateway <Edge_Gateway_Name
> to organization VDC network <Network_Name>
” error.
Reason: This issue occurs if the guest VLAN is enabled on the non-distributed routed network.
Workaround: Perform rollback and disable guest VLAN for the concerned Org VDC network and run the migration again.
Resolution: To be fixed in a future version of NSX-T.
Rollback fails to reconnect the source Org VDC Network to Edge Gateway
Rollback fails with "Cannot update the network with new subnet because it does not overlap allocated ip (XXX) from original range ()." error ip (XXX) from original range ()." error.
Step:
Reconnecting the Source Org VDC Network to the Edge Gateway.
Reason: This error occurs if the present routed vApp network has a manual NAT IP translation rule and the assigned external IP does not belong to the static IP pool of the parent Org VDC network.
Workaround: Add the external IP used in the NAT IP translation rule which belongs to the static IP pool of the NSX-V backed parent Org VDC network.
The deletion of the metadata key fails in case of a forward slash (/) present in the name of the key
The migration tool creates an Org VDC metadata key with a network name appended to it which causes metadata deletion failure if the network name is represented with a forward slash (/) in it.
Impact: No impact from a migration perspective.
Workaround: Remove the forward slash ‘/’ character from the network name if exists.
Resolution: It will be fixed in a future version of VMware Cloud Director 10.4.1 release.
The migration tool supports only a single port for the Load Balancer Virtual Server
The Migration tool will migrate Load BalancerVirtual Servers with a single port only. Load Balancer virtual servers containing multiple ports will not be migrated.
Workaround: Create multiple virtual servers as per the requirement.
VM traffic disconnects for a significant time during rollback
Reason: During rollback from NSX-T-backed Org VDC to NSX-V-backed Org VDC, the VM traffic disconnects for a significant time.
Workaround:
Reboot the VM.
Disconnect and reconnect the NIC(s) of Virtual Machine from VMware Cloud Director tenant portal UI.
Resolution: Workaround has been added in migration tool 1.4.1, to avoid this issue wherein the workload VMs will be added to the NSX-T exclusion list before vMotion. This workaround in the migration tool will be applied to NSX-T 3.2.0 and later versions.
Transparent Load Balancer Avi version check returns the wrong version
Reason: Avi version 21.1.4 or higher is necessary for transparent load balancing. The migration tool checks the Avi version using VCD API. The VCD API keeps the Avi version that existed when Avi was connected to VCD, and it does not keep track of updates which causes migration tool validation failure.
Workaround: The workaround is to update the Avi controller registration in VCD UI. Adding a description to the controller would suffice.
Resolution: It will be fixed in a future version of VMware Cloud Director.
Creation of Static Route applied on segment-backed external network interface directly connected to edge gateway via service port fails in case of multiple subnets present in an external network
Reason: The migration tool creates static routes to ensure connectivity when the default gateway of NSX-T edge gateway is in the segment-backed external network that is directly connected to the edge via a service port. The service port fails when multiple subnets are present in the segment-backed external network.
Workaround: The workaround is to have only one subnet present in segment backed external network.
Resolution: It will be fixed in a future version of VMware Cloud Director.
Rollback fails to move the standalone VM when connected with the imported network
Exception:
"[ XXXX-XX-XX-XX-XXXX ] Managed object of type "Folder" with value "group-vXXXX" does not exist.
- The object 'vim.Folder:group-vXXXX' has already been deleted or has not been completely created"
Resolution: The issue is fixed in VMware Cloud Director 10.4.1 release.
Cross vCenter migration fails during vApp/VM movement
Exception:
[xxxx-xx-xx-xx-xxxx] Internal Server Error- null Task failed, vcd-id={xx-xx-xx-xx-xx}, task-moref={ManagedObjectReference: type = Task, value = task-xxxx, serverGuid = null}, error={A general system error occurred: Connection timer out}
Reason: Incorrect vCenter URL registration string in the VCD database with port “0” suffix.
Workaround: Edit the vCenter registration in the VCD database and remove the “0” port after the URL.
Resolution: The issue is fixed in VMware Cloud Director 10.4.1 release.
vApp migration fails with NO_FEASIBLE_PLACEMENT_SOLUTION when the target Org VDC cluster is backed by only one ESXi host
Workaround: make sure vSphere clusters have at least two ESXi hosts.
Cross vCenter VM vMotion fails with an error in VMware Cloud Director 10.4.1 or newer
Exception:
failed to update and has been rolled back. null Underlying system error: com.vmware.vim.binding.vim.fault.SSLVerifyFault
Resolution: make sure that both vCenters trust each other with their VMware Certificate Authority (VMCA) certificate. For more information, refer to KB Article.
VLAN-backed external network cannot be connected to Tier-1 GW when the same VLAN ID is used for one of the Edge Node uplinks.
Workaround: Use different Edge Cluster for Tier-1 GW to avoid VLAN conflict on the same Edge Node.
Migration tool does not enable exclusion/negation for the gateway firewall rules and distributed firewall rules after migration
The migration tool does not enable exclusion/negation for the gateway firewall rules and distributed firewall rules that had exclusion/negate enabled at the Source/Destination. As a result, such migrated rules act in the opposite way than intended.