picture of parabolic satellite dish space technology receivers, china
VMware Cloud Director VMware Cloud Provider

VMware NSX Migration for VMware Cloud Director 1.3 – Technical Overview

We are thrilled to announce that the VMware NSX Migration for VMware Cloud Director 1.3 version is now generally available! Closely following the 10.3 version of VMware Cloud Director, which brought several critical networking and security features (routed vApp networks, dynamic security groups, etc.), this 5th iteration of the NSX Migration for Cloud Director brings several key elements:

  • Support for shared networks 🥳
  • Independent (named) disks
  • Fast provisioning support
  • DHCP services support on isolated vApp networks
  • Distributed firewall with dynamic groups
  • Dual-stack (IPv4/IPv6 on the same vNIC) organization VDC network
  • DNS forwarder IP address re-configured on target networks
  • Additional IPsec encryption algorithms: AES, AES-GCM
  • Assessment mode improvements

Another significant improvement concerns the migration workflow itself. The NSX Migration for Cloud Director tool is now modular: instead of going from A to Z during a migration, you now have the opportunity to interact with the workflow by using breakpoints for better control of the overall process.

Let’s dig into some details! 👇

Shared Networks Support

Based on various feedback and the first results of assessments shared with us, we knew that shared network support was the main blocker for many cloud providers.

shared network is an organization VDC network with a “Share” flag set to true, making it available to other virtual data centers within the same organization; the virtual data centers need of course to have fabric access to the network port groups.

VMware Cloud Director: Shared Network Option

For NSX-T backed organization VDCs, such sharing was not possible up to VMware Cloud Director version 10.2. Version 10.3 has added the ability to share directly connected organization VDC network connected to external VDS port group backed network.

The alternative mechanism for “sharing” organization VDC networks across NSX-T backed organization VDCs is via the consumption of a Data Center Group. Organization VDC networks added to a data center group are accessible to all the organization VDCs participating in the data center group.

Shared networks were not supported for the migration until now: the main reason is that we are migrating organization VDC by organization VDC. We had to rethink the migration process to migrate multiple organization VDCs in a single time.

With the NSX Migration for Cloud Director 1.3 release, when a shared network is present in a virtual data center that is going to be migrated, all organization VDCs that have vApps connected to the shared network must be migrated together (supported maximum is 16 organization VDCs).

The system administrator must provide a list of organization VDCs to migrate together in the YAML user input file (associated with their specific parameters).

The migration tool will create the required data center group(s) and add all organization VDCs migrated together to the relevant data center groups.

Directly connected organization VDC network to an external network used also by other organization VDCs (typically Service Network use case) will not be migrated via the data center group mechanism. Instead, the system administrator must create an identically named external network with the suffix “-v2t” before the migration: this external network must be backed by an NSX-T segment configured with same VLAN as the source external network.

The diagram above shows an example organization with four virtual data centers (A to D). There are two shared networks (Org VDC Network A and Org VDC Network C). You can notice that Org VDCs A, C and D must be migrated together as each of them has a vApp connected to the shared networks.

In the above scenario, the specification file will need to include organization VDCs A, C and D: however, the inclusion of organization VDC B is optional but allowed. The reasoning is that while organization VDC B does not currently have any vApp attached to a shared network, it might in the future, and we want to enable that Org VDC to have access to the shared network. The result post-migration is below.

One more thing: there are situations where shared networks are configured but not used. We have seen multiple situations where that was true: e.g., 2 organization VDCs, but no VMs in the 2nd virtual data center connected to the networks that are shared.

In such context, an easier way to migrate would be to “un-share” the concerned networks and migrate organization VDC by organization VDC.

Note: all shared network migration scenarios are detailed in the User Guide.

Bringing Modularity to the Migration

Until 1.2.1, we had no opportunity to interact with the NSX Migration for Cloud Director tool during a running migration. The 1.3 release introduces modularity into the process with the breakpoint feature, allowing a system administrator to skip or run a specific workflow.

The workflows can be executed in the sequence mentioned below:

  1. topology – Replication and preparation of target organization VDC(s), edge gateway(s), organization VDC network(s), etc.
  2. bridging – Automatic L2 bridging configuration between source and target organization VDC networks.
  3. services – Configuration of networking services (NAT, firewall, etc.) and North-South traffic switch over.
  4. movevapp – Workload migration (vApps/VMs).

Please note that unless otherwise instructed, the NSX Migration for Cloud Director will execute the migration in a single pass (without skipping a step or running one in particular).

VMware NSX Migration for VMware Cloud Director 1.3: breakpoints brings flexibility

One might wonder what could be the use cases for such a feature? There may be a need for more control of the overall process depending on the migration requirements, the current VMware Cloud Director implementation, or how the tenants consume networking and security services.

Below are a few examples:

  • Avoid bridging – For technical reasons, some Cloud Providers may want to avoid L2 bridging.
  • Additional verification from your operations team – We received several feedback where the operations team had a requirement to pause the migration to do additional checks.
  • Allows the system administrator to skip vApp migration – Workload migration may be difficult (large quantity of data to migrate) or even not possible (related to the vMotion process) in some circumstances. For those situations, you can skip the workload migration workflow and delegate it to an external tool (such as VMware Cloud Director Availability), or even do it manually.


  • Even if not specified in an ‘execute’ command, the topology replication (‘topology’) workflow will be mandatorily executed.
  • Automated rollback is compatible with the breakpoints.

General Enhancements & Usability

This 1.3 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 a better usability and migration experience.

  • Named (a.k.a. Independent) disk migration has been added as a new feature in VMware Cloud Director 10.3. Standalone or connected (but not shared) can now be migrated during an NSX-V to NSX-T migration, starting with the NSX Migration for VCD 1.3 release.
  • Fast provisioning support – Fast provisioning saves time by using linked clones for virtual machine provisioning operations.
  • DHCP services support on isolated vApp networks
  • Assessment mode improvements – As the NSX Migration tool and VMware Cloud Director capabilities evolve, we had obviously to update the tests conducted by the assessment mode as well as the generated report results.
  • Distributed firewall with dynamic groups – VMware Cloud Director 10.3 added support for VM security tags and dynamic security groups. NSX-V dynamic security groups are now supported in the migration process.
  • Dual-stack (IPv4/IPv6 on same vNIC) Org VDC networks
  • DNS forwarder IP address re-configured on target networks – DNS listener IP address will change after the migration. The new IP address will be updated in the concerned organization’s VDC network configuration but will not be applied to already deployed VMs.
  • Additional IPsec encryption algorithms: AES, AES-GCM


Developed by the Cloud Services Business Unit (CSBU), the VMware NSX Migration for VMware Cloud Director is the solution you’re looking for to migrate NSX-V 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 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. Whether you haven’t started thinking about the NSX-V to NSX-T migration yet, or are in the planning phase, the assessment mode is a key part of the process. So, don’t be shy, try it! 😉

This migration tool has a different release cycle than VMware Cloud Director, and we 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 here in the comments section, in social media (@woueb), or via your VMware representative.

Additional resources:


14 comments have been added so far

  1. Hello,
    Thanks for job done!
    However, I’m facing following issue with version 1.3 :
    [vcdNSXMigrator]:[run]:988 [ERROR] [MainThread]| ‘NoneType’ object has no attribute ‘get’
    Everything was fine with v. 1.2.1

    Is there a way to have some support on this tool please?


      1. If you have specified Verify as False in the input YAML file and have commented out the ‘CertificatePath’, you will also need to comment out the ‘Common’ keyword in input file.

        Or you can uncomment the ‘CertificatePath’ as you have already specified ‘Verify’ as False so ‘CertificatePath’ does not matter.

        1. That’s it!!!
          Thanks a lot Romain!

          Worked after having commented ‘Common’ keyword
          By the way, that’s a change from v1.2.1 that I’ve may have missed 😉

  2. That’s it!!!
    Thanks a lot Romain!

    Worked after having commented ‘Common’ keyword
    By the way, that’s a change from v1.2.1 that I’ve may have missed 😉

    1. Hi Romain,

      I’ve been following your VCD content lately as Ive needed to perform some NSX-V to T migrations. I’m testing the migration in the lab and I’ve got version 1.3.2 and I am getting the Input error as well. I have tried to comment out the necessary lines as stated above but Im still getting the following:

      2022-05-05 11:47:52,300 [vcdNSXMigrator]:[run]:1037 [ERROR] [MainThread]| ‘NoneType’ object has no attribute ‘get’
      Traceback (most recent call last):
      File “src\vcdNSXMigrator.py”, line 993, in run
      File “src\vcdNSXMigrator.py”, line 328, in inputValidation
      AttributeError: ‘NoneType’ object has no attribute ‘get’

      Not much more is available in the logs. Any other suggestions?

      1. Are you in the Slack Workspace for Cloud Providers? If yes, ping me there with more details, the yaml file and the log file.
        Otherwise, I’d suggest to open an SR.


  3. Hello Romain,
    thanks for this blog post. I’m trying the migration script but i’ve an error during pre-checks:

    [vcdNSXMigrator]:[run]:678 [ERROR] | Cannot continue due to the following error/s:
    Org VDC “Pod-140-OrgD-VDC-01” does not exist

    But Org VDC “Pod-140-OrgD-VDC-01” exists and correctly belong to “Pod-140-OrgD”

    Also, if i run the script in assessment mode without specifying any OrgVDC but only Organization it discover it correctly.

    Any ideas? Thanks.

    1. Hum, not sure about that one. Do you have maybe some special (hidden?) characters in the yaml file at the end of the org VDC name? The fact that it works w/o specifying the org VDCs tend to demonstrate that it’s a formatting issue in the YAML.

      1. Hi Romain, tried many times to delete all spaces at the end of each lines but unfortunately I still have the same error. Is there some “limit” on Org or Org VDC names? Length, allowed characters ..?

  4. Hi Romain, I’ve found the issue. Your previous message pointed me in the right direction! I had an “hidden” space in the Org VDC name but in vCD and not in YAML file.. Thank you for your suggestion.

  5. Hi Romain, by any chance do you know why DNAT is not supported on a tier-1 gateway where policy-based IPSec VPN is configured? We have a number of Tenants using this configuration in vcd/nsx-v. Wondering if their is a work round that does not shift config up to tier-0 where the customer will lose sight of the configuration.

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.