VMware NSX Migration for VMware Cloud Director 1.3.3 | 07 JUN 2022
Check for additions and updates to these release notes.
What's New
The NSX Migration for VMware Cloud Director tool version 1.3.3 supports several new features:
Routed vApp enhancements: Support for additional routed vApp network configurations:
All combinations of vApp network types are supported
Support for disabled NAT service.
Support for the combined 'TCP & UDP' protocol in NAT forwarding rule.
Enhanced Cross VDC networking validation: The migration tool will check for the presence of cross VDC networks in Org VDCs instead of the global vCenter setting. This enhancement provides accurate assessment results.
Tier-0/VRF gateway route re-distribution: The migration tool will apply the route re-distribution rules on the Tier-0/VRF gateway to advertise Tier-1 gateway services. This will fix an issue where the external connectivity was not working after migration. Following Tier-1 networking services for route re-distribution will be set if not set already.
Static Routes
NAT IP
LB VIP
IPSec Local Endpoint
Additionally, the following services will be set if static or dynamic routing is enabled on T1.
Connected Interfaces & Segments
Service Interface subnet
Connected Segment
Support multiple subnets in the NoSnatDestinationSubnet field: You can provide multiple subnets in the user input YAML file to configure the NOSNAT Rules.
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.
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.
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.
After migration to NSX-T, NAT rules are not editable through VMware Cloud Director UI
After the migration is completed, the NAT rules created at target are not editable using VMware Cloud Director UI. A lock symbol can be seen while selecting NAT rules.
NAT rule through VCD UI
Workaround: Use VMware Cloud Director API to edit the NAT rules. Issue fixed in VMware Cloud Director 10.3.2.
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.
DNAT rules will not be created on non-distributed networks belonging to a Data Center Group (NSX-T backed)
When non-distributed routing is enabled on Org VDC networks with NSX-T data center and DNS IP same as the default gateway IP on that network, then the migration tool will create two DNAT rules to handle the DNS traffic. These 2 DNAT rules will not get created if the Org VDC network is part of the Data center group.
Will be fixed in the future VMware Cloud Director version.
Workaround: Create DNAT rules manually for DNS traffic after migration.
Migration of encrypted VM fails
Migration of encrypted running VM across the PVDC/Org VDC fails with "A powered-on encrypted VM is not allowed to change its profile." even though the underlying VC policy is not changing.
A powered-on encrypted VM is not allowed to change its profile. Initial VM home policy: Encrypted-Performance. Initial disk policies: {VmDiskRef [diskObjectId=2000]=Encrypted-Performance}. Target VM home policy: Encrypted-Performance. Target disk policies: {VmDiskRef [diskObjectId=2000]=Encrypted-Performance}.
Workaround: Power off such encrypted VM during the migration.
Resolution: The issue is fixed in VMware Cloud Director 10.3.3 release.
Migration of VM with disconnected NIC fails
Migration of VM fails if a network is assigned to the VM NIC, but it's in disconnected state (by unchecking the "Connected" box in VMware Cloud Director Tenant Portal).
Workaround: Set the Network value for the VM to "None".
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-disturbuted 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.
Migration of isolated vApp network fails with DHCP
Migration of isolated vApp network will fail if DHCP is configured on the isolated vApp network.
Workaround: Disable DHCP on the isolated vApp network and run the migration.
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 is having 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.
Migration of routed vApp network fails at multiple NAT rules with the same External port
Migration of vApp with routed vApp network fails with "Cannot use the same port XXX as an external port for two different port forwarding NAT rules."
Reason: This error occurs when there are multiple NAT port forwarding rules in a routed vApp network with the same external port (even if the protocol is different for the rules).
Workaround: Use a single 'TCP & UDP' rule instead of separate rules for 'TCP & UDP' protocols.
It will be fixed in a future version of VMware Cloud Director.
Migration fails to create a security group
Migration fails during the creation of a security group for the non-distributed Org VDC network with a similar error as following:
Exception:
Failed to create Security Group - [ xxx-xx-xxx ] Invalid Network XXX specified for Firewall Group YYY as it is not connected/scoped to ZZZ
Workaround: None
It will be fixed in a future version of VMware Cloud Director.
Deletion of metadata key fails in case of '/' character being present in the name of the key
The migration tool creates an Org VDC metadata key with network name appended to it which causes the metadata deletion failure if network name happen to have / character in it.
Impact: No impact from migration perspective.
Workaround: Remove / character from network name if exists.
It will be fixed in a future version of VMware Cloud Director.
