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.0 | 20 SEP 2022

Check for additions and updates to these release notes.

What's New

The NSX Migration for VMware Cloud Director tool version 1.4.0 supports several new features:

  • Parallel migrations: You can run multiple migration instances with bridging at the same time using the same or different bridge edge cluster(s). Should the same bridge edge cluster be used, the bridging Transport Zone and Bridge Uplink Profile will be unique for each migration instance. The bridging edge cluster can be used by multiple parallel migrations but depends upon the availability of edge transport nodes in the clusters. Each edge transport node can be used by single migration only.
  • Static Routes migration: The migration tool will migrate the internal static routes configured on the edge gateway. Internal static routes correspond to those static routes that route traffic within the Org VDC (the next hop is from Org VDC network IP space). This feature will be supported only with VMware Cloud Director version 10.4 or higher.
  • Granular Edge Gateway parameters: You can now provide the following granular edge parameters per gateway in the user input YAML file:
    • Tier0Gateways
    • NoSnatDestinationSubnet
    • ServiceEngineGroupName
    • LoadBalancerVIPSubnet
    • LoadBalancerServiceNetwork
    • LoadBalancerServiceNetworkIPv6
    • AdvertiseRoutedNetworks
    • NonDistributedNetworks
    • ServiceNetworkDefinition
    Note:

    Specifying granular edge gateway parameters is optional. If parameters are not provided at the edge gateway level in the user input YAML file, then the parameters specified at the Org VDC level will be used.

  • Migration of edge gateway without default gateway: You can migrate edge gateways that have no default gateway configured.
  • External Network/Tier-0 Gateway static IP pool having single IP: The migration tool will not fail with an error anymore during cleanup/rollback when only single IP is present in the External Network/Tier-0 Gateway static IP pool. To achieve this, the newly added field EmptyIPPoolOverride must be set to True in the user input YAML file. Since the IP is not removed by the migration tool it is the user’s responsibility to remove the IP manually to prevent potential IP conflict.
  • IPV6 support in Load Balancer virtual service: The migration tool now supports both IPv4 and IPv6 addresses to be configured in Load Balancer virtual service and pools. This feature will be supported only with VMware Cloud Director version 10.4 or higher.
  • ANY in TCP/UDP rule in NAT/Firewall/DFW: You can migrate gateway firewall and distributed firewall rules with TCP/UDP protocol having ‘any’ specified in its source or destination service. Similarly, you can migrate NAT rules with TCP/UDP protocol and ‘any’ specified as a port.
  • Custom service network for edge gateway DNS and DHCP services: DNS forwarding and DHCP server networking services running on NSX-T edge Gateway uses IP addresses from the service network subnet which is by default 192.168.255.225/27. If this subnet clashes with an existing NSX-V Org VDC network, then the serviceNetworkDefinition field is added in the user input YAML file to create an Org VDC edge gateway with a custom service network.
  • Migration of DFW on external network: You can now migrate DFW rules set on direct networks. The migration tool now supports DFW rules on external network that are being migrated as imported networks (VLAN segment backed) to target Data Center Group.
  • vApp states: Empty vApps and vApps in failed creation, unresolved, unrecognized, or inconsistent states will be ignored during the migration and will be deleted during the cleanup. vApps in maintenance mode will be identified as a migration blocker during pre-check.
  • NAT-IP Firewall Matching: The migration tool will create additional firewall rules when the original IP address in the DNAT rule and destination IP address in the firewall rule is the same and belongs to a Non-Distributed (SR connected) network subnet. This will ensure proper external connectivity after migration to NSX-T as the service port on SR has its firewall instance and the packets passing through will have the translated destination IP.
  • IPv6 Routing: The migration tool will advertise IPv6 subnets of Org VDC networks (single or dual stacked) if the AdvertiseRoutedNetworks field in the user input YAML file is set to True.
  • Skip BGP Migration: The migration tool will not migrate the BGP configuration if the SkipBGPMigration field in the user input YAML file is set to True.
  • Log Files: The directory structure of logs has been changed.

    Logs can be found in the following directories:

    • Migration logs can be found in the Migration directory Logs>VCD- (IP/FQDN of VCD)->
    • Assessment logs can be found in the v2tAssessment directory Logs>VCD- (IP/FQDN of VCD)->
    • Additionally, the migration logs name is prefixed with the organization name to identify logs easily. Assessment reports can be found in the 'reports' folder.

Important Note

DNAT not supported for Policy-based VPN on Edge Gateway: while NSX-T 4.0.0.1 supports the DNAT/NO-DNAT rule configuration that matches traffic decapsulated from the Policy-based VPN., this NSX-T version is not yet supported by the VMware NSX Migration for Cloud Director. This specific structure will not be blocked during the migration process (and will generate a warning in the logs) but the packet processing may not work as expected after migration.

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.

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.

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

Workaround: Create DNAT rules manually for DNS traffic after migration.

Resolution: The issue is fixed in VMware Cloud Director 10.3.3 release.

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

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

Resolution: The issue is fixed in VMware Cloud Director 10.3.3.2 and 10.4 releases.

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

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

Resolution: The issue is fixed in VMware Cloud Director 10.3.3.2 and 10.4 releases.

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

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

  1. Reboot the VM.
  2. Disconnect and reconnect the NIC(s) of Virtual Machine from VMware Cloud Director tenant portal UI.

Resolution: It will be fixed in a future version of NSX-T.

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