VMware NSX Migration for VMware Cloud Director Frequently Asked Questions

This page provides answers to commonly asked questions in the context of NSX for vSphere to NSX-T migration in a VMware Cloud Director environment.

Frequently Asked Questions

What does an NSX-V to NSX-T migration look like with the VMware NSX Migration for Cloud Director?

The VMware NSX Migration for VMware Cloud Director tool provides per organization VDC automated migration to a new vSphere cluster under NSX-T management. It minimizes network downtime with bridged networks during migration.

CLI-based automation tool that initiates and migrates an NSX-V organization virtual data center to an NSX-T organization virtual data center with a minimum downtime: replication followed by a live migration of the workloads.
The only solution available to migrate an NSX-V environment with VMware Cloud Director in an automated way and with limited downtime.

Where can I download the VMware NSX Migration for Cloud Director?

The VMware NSX Migration for Cloud Director is available via the VMware Cloud Director download page, under "Drivers & Tools". For each version, you will find a package for Windows, a package for Linux, the User Guide, and the Release Notes.

Does the use of the migration tool require any specific edition of VMware Cloud Director?

It depends on the migration tool version. Nevertheless, the newer VMware Cloud Director version you have, the more features can be migrated. For that reason, we recommended upgrading to the latest VMware Cloud Director. The VMware Product Interoperability Matrix lists all product versions with the NSX Migration for Cloud Director.

We ran the assessment, and the report list a few organization VDC that "Can be migrated with additional preparation work". What should be our next steps?

Those organization virtual data centers include features that can be mitigated to allow an automated migration. Possible mitigation steps for features are described in the Possible Mitigation Steps for Features table in the User Guide. The detailed assessment report can be used to identify which features have to be mitigated for every organization virtual data center. Mitigation steps should be performed prior to attempting to migrate. Running the assessment again will help to validate that the concerned organization VDC(s) are ready for migration.

We ran the assessment, and the report list a few organization VDC with the following status: "Automated migration not supported with the current version". Do I have to wait for a new NSX Migration version before beginning the migration?

No. The migration should be started as soon as possible. The VMware NSX Migration for Cloud Director provides granular migration capability with the organization VDC being the unit of migration: in other words, you migrate organization VDC by organization VDC (or pack of organization VDCs together). Most likely, some organization VDC are already listed as "Can be migrated".

Recommended steps:

Check the Possible Mitigation Steps for Features table in the User Guide.
Upgrade VMware Cloud Director if required.
Install NSX-T and make sure to meet all requirements.
Deploy NSX-T backed external networks (Tier-0 GWs, VRFs, segments) to match NSX-V external network topology and configure them in VMware Cloud Director.
Start to migrate the organization virtual data centers listed as "Can be migrated".
Mitigate the organization virtual data centers listed as "Can be migrated with additional preparation work", then migrate those.
For the remaining ones, please contact your VMware account team for further clarification or wait for the next version of the NSX Migration for Cloud Director tool.

We want to migrate to a new VMware Cloud Director instance: is that supported by the VMware NSX Migration for Cloud Director tool?

No. The NSX-V to NSX-T migration is done from a VMware Cloud Director point of view. System-wide objects (such as organizations, users, groups, etc.) are not migrated. An option would be to use VMware Cloud Director Availability (VCDA) for workload migration from a VMware Cloud Director instance with NSX for vSphere site to a VMware Cloud Director instance with NSX-T site. However, VCDA does not replicate organizations, users, org VDCs and network objects (networks, edge gateways, etc.): those would have to be duplicated manually or using a custom script in the target environment.

We can't do a hardware refresh now, and we don't have buffer hardware: what are our options?

Reclaim and repurpose compute! The migration is granular, and the unit of migration is the organization VDC (or a "pack" of organization VDCs): you can start with very small target NSX-T cluster and swing ESXi hosts from source NSX-V clusters to the target NSX-T clusters as they are freed during each migration.

Some free capacity will be required to create the first NSX-T cluster to start the migration.

Consider temporarily reducing the availability configuration in one or more vSphere clusters or increasing the over-allocation of resources to allow the removal of one or more ESXi host(s) from each vSphere cluster.

Some NSX-V components are created directly outside VMware Cloud Director; is that supported for the migration?

The migration is done from a VMware Cloud Director point of view; only services supported by VMware Cloud Director and NSX-T integration will be migrated. The NSX Migration for VMware Cloud Director will not migrate objects and components directly created and managed from NSX-V. While not supported using the VMware NSX Migration for Cloud Director, custom scripts, manual actions, or 3rd parties can also be used to migrate those objects external to VMware Cloud Director.

Our tenants use the NSX-V SSL VPN feature; I heard this feature wasn't ported to NSX-T?

NSX-T does not include a client VPN solution that we can expose to replace the NSX-V SSL VPN feature. We recommend that partners follow the guidance provided in VMware Cloud Director Remote Access VPN Integration Guide and transition to other solutions. There are no plans to return a remote access client feature in NSX-T. The transition to another solution should be completed prior to the NSX-V to NSX-T migration.

We are currently using Hardware VTEPs to extend VMware Cloud Director networking to physical devices; what are our options?

The use case that led to the consumption of hardware VTEPs will influence the NSX-T design and configuration. NSX-T offers many additional possibilities than NSX for vSphere:

L3 would be the best recommendation (connect the physical workloads to the Tier-0/VRF gateway)
The servers connected to the hardware VTEPs could be considered as bare-metal servers participating in the NSX-T fabric
L2VPN or L2 Bridging are potential alternatives

We want to understand better the downtime that our customers will experience: what do you mean by "limited downtime"?

East-West connectivity is maintained during the length of the migration with an automatic configuration of L2 bridging between source and destination organization VDC networks. North-South downtime happens during the "switchover" phase: at this moment, source edge gateways are disconnected from external networks, and the destination external networks are connected. The length of the downtime depends on the number of external networks as well as the number of edge gateways and associated services (NAT, LB, FW, etc.). We observe between 1 and 6 minutes of total downtime during our tests for a single organization VDC. Independently of the downtime, the length of the maintenance windows mainly depends on the storage:

if a shared storage exists between NSX-V and NSX-T clusters (e.g., NFS, ISCSI, FC), it will be a simple vMotion with no data movement
if the storage is dedicated to each cluster (vSAN), the migration will include a data movement (with Storage vMotion)

Will the UUIDs of vApps and VMs change with the migration?

The NSX Migration for VMware Cloud Director performs a live migration of vApps and VMs using the MoveVApp API: as such, vApp and VM identities and UUIDs are preserved.

We want to skip the workload migration; is that possible?

We understand that in some situations, cloud providers may want to skip the workload migration (for better control or because vMotion is not possible at the vSphere level). From 1.3 and onwards, it is possible to skip specific workflow(s) during the migration using breakpoints. With regards to workloads migrations, several alternatives are possible:

Use the MoveVApp API manually (preserve vApp and VM identities).

Use VMware Cloud Director Availability to migrate the VM to the destination NSX-T organization VDC: please note that such migration doesn't preserve the workloads' identity / UUID.

Use the Move option available in the VMware Cloud Director CLI and UI: please note that it does a clone and delete operations (not vMotion), which doesn't preserve the identity. Also, the VM/vApp must be powered off.

VMware Cloud Director Availability protects our NSX-V workloads; is this a problem?

The NSX migration tool does not understand if VMs are backed up or replicated by external tools (such as VMware Cloud Director Availability); we are looking for ways of improving that. As of now, the recommended steps are:

Do a failover for the concerned VMs: VCDA will consider the source inaccessible and leave it untouched and ready for migration. Destination VMs can be left powered off after the failover. Please note that this action is not disruptive and that there is no conflict if the destination VMs are left powered off.
(Optional) In case the migration is between two different vCenters with non-shared SSO domain (possible with the NSX Migration for Cloud Director 1.3.1 and onwards), a separate VCDA instance is required. This new VCDA instance will be connected to the same destination VCDA instance.
Migrate the concerned organization VDC(s) with the NSX Migration for Cloud Director tool.
After the migration, create a new replication with the destination VMs as seed (to avoid a full sync).

We are using IPv6 in our NSX for vSphere environment; is that supported for the migration?

Yes. In order to correctly migrate IPv6 networking features, the target NSX-T manager must have IPv6 L3 Forwarding Mode enabled in the Global Network Configuration.