This site will be decommissioned on December 31st 2024. After that date content will be available at techdocs.broadcom.com.

 

VMware NSX Migration for VMware Cloud Director 1.4.2.1 | 09 November 2023

Check for additions and updates to these release notes.

What's New

The NSX Migration for VMware Cloud Director tool version 1.4.2.1 release contains bug fixes that resolved the following issues:

  • SNAT/Firewall: If a firewall rule is created for an SNAT, where the SNAT is created on the service Interface, the migration tool will migrate such rule with the Applied Section as ‘None(or empty)’ on NSX-T, thus allowing the NAT traffic that was previously blocked if there was deny any/any rule.

  • None PVDC migration: The migration tool will not migrate an Org VDC with source provider VDC as ‘None’ type (Org VDCs backed by PVDC/vCenter without NSX). The migration tool will throw the following exception:

  • Migration on ICMP Firewall rules: In the earlier versions, if a firewall has ICMP (capital letters) configured, the migration tool fails with an error. In the current 1.4.2.1 release, the issue has been resolved and any ICMP firewall capitalization (ICMP/IcMp) is accepted.

  • VRF/T0 renaming issue: You can migrate an Org VDC which uses a different VRF/Tier0, that was renamed in NSX after its creation, and thus its display name and NSX Policy API path name is different.

  • Load Balancer “Key error” for Transparent mode Load Balancer: The migration tool will not fail with an error anymore during migration if the Transparent mode is configured in Load Balancer. Furthermore, in the Assessment Report, the fields related to Edge gateway will show the appropriate section marked as "False" instead of marking it as an Error.

  • EmptyIPPoolOverride issue: The migration tool now will not remove the last IP address from the sub-allocated pool of the source edge gateway from the source external network when the ''EmptyIPPoolOverride" flag is set to "True".

  • Load Balancer using the same certificate in different Application Profiles: The migration will now allow the migration of Load Balancer using the same certificate in different application profiles.

  • Migration tool does not find VCD external networks: Previously the migration tool failed to fetch the VCD external network because of too many VCD external networks present in the Cloud Director and the API response was paginated without sorting. The migration tool will now fetch the VCD External Networks in ascending order to resolve such issues.

  • Exclusion list enhancement: The migration tool 1.4.2.1 supports the NSX-T Distributed Firewall Exclusion list for direct networks, which prevents vMotioned VMs during rollback from temporarily losing network connectivity. This feature was available for only routed networks in earlier versions.

Important Note

  • IPSEC VPN on Service Interface is unsupported: The migration tool will block the migration of IPSEC VPN configured on Service Interface since it is NSX-T limitation. For more information, click here to refer to the NSX-T and Service Interfaces PPT.

Known Issues

  • 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.

Resolution: The issue is fixed in NSX-T version 3.1.3.3 (for more details, see NSX-T Release Notes).

  • VMs connected to distributed Org VDC networks lose network connectivity after the N-S network switchover

VMs connected to distributed Org VDC networks lose network connectivity after the 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 is 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: The issue will be fixed in NSX-T version 4.1.1.

  • 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: The issue is fixed in 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 Balancer Virtual 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:

  1. Reboot the VM.

  2. Disconnect and reconnect the NIC(s) of Virtual Machine from the 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.

Note:

If the Org VDC has only direct networks (and no routed networks), the migration tool will not add such networks to the exclusion list thereby causing downtime. To avoid this, just add a dummy routed network to the Org VDC. If the direct network is added to some data center group, then a dummy routed network should be added to that data center group as well.

  • 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: The issue will be fixed in a future version of the VMware Cloud Director release.

  • 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: The issue is fixed in VMware Cloud Director 10.4.2 release. 

  • Rollback fails to move the standalone VM

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 the 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 fails for vApp/VM with snapshot for cross vCenter migration

Exception:

Internal Server Error\n - VM xxx (xxxxx-xxxx-xxx-xxxx-xxxxxxxxx) failed to update and has been rolled back. null Underlying system error: com.vmware.vim.binding.vim.fault.DiskMoveTypeNotSupported

Workaround: Remove the snapshot before migration.

Resolution: The issue will be fixed in a future version of the VMware Cloud Director release.

  • NSX-T Edge Gateway connected to IP Space enabled Provider Gateway (public) loses Routed Org VDC network advertisement configuration during migration after edge gateway is reconnected to Tier-0/VRF

Reason: Migration tool during its service configuration step enables route advertisement of routed Org VDC networks that are being advertised and connected to edge gateway having its uplink connected to IP Space enabled Public Provider Gateway. Once target-routed Org VDC networks are reconnected to the NSX-T edge gateway, the migration tool reconnects the NSX-T edge gateway to Tier-0/VRF. During this reconnection of the edge gateway to the Tier-0/VRF edge gateway, the NSX-T edge gateway loses routed Org VDC networks advertisement info connected to its interfaces.

Workaround: After the reconnection of NSX-T edge to Tier-0/VRF, follow the steps below:

  1. Go to each Advertised routed Org VDC network connected to edge gateway with uplink connected to IP Space enabled Public Provider Gateway.

  2. Click Edit and then click Save. This will restore routed Org VDC networks advertisement configuration in the NSX-T edge gateway.

Resolution: The issue will be fixed in a future version of VMware Cloud Director.

  • Move vApp fails to retain external IPs for powered-off routed vApp.

     While creating a routed vApp network (connected to VMs) connected to an Org VDC network, after migration, the primary IPs are retained but external IPs are not retained even after "Retain IP/MAC Resources" is enabled.

Reason: After migration, the powered-off routed vApp has external IPs in a "pending" state.

Resolution: The issue will be fixed in a future version of VMware Cloud Director.

check-circle-line exclamation-circle-line close-line
Scroll to top icon