VMware Cloud Director VMware Cloud Provider

NSX Migration for Cloud Director 1.3.2 with Routed vApp Network Migration

Developed by the Cloud Infrastructure Business Group (CIBG), the VMware NSX Migration for VMware Cloud Director is THE solution you’re looking for to migrate NSX for vSphere to NSX-T if you are running a VMware Cloud Director environment: it is an external automation tool that initiates and complete the migration process with minimum downtime.

We are thrilled to announce that the VMware NSX Migration for VMware Cloud Director 1.3.2 version is now generally available!

To constantly improve your ability to migrate from NSX for vSphere to NSX-T, this 7th iteration of the NSX Migration for Cloud Director brings several key migration capabilities:

  • Support for routed vApp network migration (including vApp edge networking services)
  • UTF-8 characters support to migrate VMware Cloud Director objects having names and descriptions with special characters or non-Latin-based languages
  • Support for Edge Gateway Rate Limits migration
  • Non-Distributed Routing support with NSX-T Data Center
  • Enhanced Direct Network Migration
  • General enhancements and usability (see below for more details)
  • Updated assessment mode

Please check the VMware NSX Migration for VMware Cloud Director 1.3.2 release notes for a detailed list.

Routed vApp Networks Migration

vApps are a core feature in VMware Cloud Director and useful for grouping VMs for application needs. vApps networks can either be constructed with or without services. Networks without services are either simple isolated vApp networks or direct vApp networks (i.e., a logical extension of an organization VDC network). However, vApp networks can also be configured with firewall, NAT, static routing, and DHCP services. These services are used to created vApps with network security and isolation, effectively encapsulating its members.

Networks configured with services are typically referred to as routed vApp networks; a typical use case for routed vApp networks is for dev/test environments. Isolated networks can also be configured with DHCP services.

VMware Cloud Director 10.3 introduced the support for routed vApp networks (a.k.a. vApp Edge services) for NSX-T backed organization virtual data center: vApp edges are deployed as standalone Tier-1 gateways connected to an overlay organization VDC network via a service interface.

NSX-T routed vApp network diagram in VMware Cloud Director (VCD) 10.3

Starting with version 1.3.2, the NSX migration for Cloud Director supports the migration of routed vApp networks with the following considerations:

  • This feature requires VMware Cloud Director 10.3.2.1 or newer
  • vApp edges can only be connected to overlay-backed organization VDC networks (thus, routed vApp parent network cannot be a directly connected org VDC network)
  • Routed vApp network is not supported with other types of networks in the same vApp

General Enhancements & Usability

This 1.3.2 release includes many other new features, but the goal is not to go through all items in this blog post. While some may seem minor, their number and benefits bring better flexibility and migration experience.

  • Non-Distributed Routing with NSX-T Data Center: you can now enable non-distributed routing on routed organization VDC networks (such networks are connected via service interface directly to service router of Tier-1 gateway). Non-distributed routing will be enabled on organization VDC networks routed via an internal interface in one of the following two cases.
    • Explicitly via setting input parameter NonDistributedNetworks in the YAML file.
    • Implicitly if DNS relay is enabled and DNS IP is the same as Default Gateway IP. This together with auto-configured DNAT of Default Gateway IP to DNS Forwarder IP will achieve the availability of DNS services on the same IP for migrated VMs.
  • Enhanced Direct Network Migration: you are now able to force migration of directly connected organization VDC networks to a different external network with -v2t suffix for service network use case.
  • Multiple Tier-0 Gateways Support: you have an option to specify individual Tier-0 Gateways for each Edge Gateway in Org VDC. It is no longer mandatory to connect all target Edge Gateways to a single Tier-0 Gateway.
  • Renamed ExternalNetwork toTier0GatewaysExternalNetwork field in the user input YAML file which specifies the NSX-T Tier-0 Gateway is renamed to Tier0Gateways to match the name in the VMware Cloud Director user interface.
  • Optional Tier0Gateways and DummyExternalNetwork: these two fields in user input YAML can be skipped if edge gateways are not present on the NSX for vSphere backed Org VDC.
  • Guest VLAN migration: routed Org VDC networks and routed vApp networks can be migrated with the Guest VLAN option enabled.
  • Disk Level Storage Policy support: you can migrate VMs with disks having different storage policies.
  • Enhanced Named Disk Migration: you can migrate named/independent disks attached to powered-on VMs without powering off those VMs. Named disks with different storage policies will also be migrated
  • Update assessment mode to take into accounts features that are now supported.

Summary

The VMware NSX Migration for Cloud Director 1.3.2 is now generally available and brings the support to routed vApp networks migration but also many additional features.

We continue to improve the scenarios and the tooling to help our VMware Cloud Providers Partners to migrate VMware Cloud Director from NSX for vSphere to NSX-T. Please don’t wait and take the advantage to redo an automatic assessment using this latest version to see how it improves your capability to migrate. 😉

This migration tool has a different release cycle than VMware Cloud Director, and we have already started developing the next version.

You are encouraged to continue providing feedback to help us decide how the tool should evolve. We would love to hear about you, either in the comments section below, in social media (@woueb), in the #vcd-v2t-assist channel on the VMware Cloud Provider Slack workspace, or via your VMware representative.

Additional resources:

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *