How to Migrate VMware Cloud Director from NSX-V to NSX-T (part 2)

This is an update of the original article with the same title published last year How to Migrate VMware Cloud Director from NSX-V to NSX-T and includes the new enhancements of the VMware NSX Migration for VMware Cloud Director version 1.2.1 that has been released yesterday.

The tool’s main purpose is to automate migration of VMware Cloud Director Organization Virtual Data Centers that are NSX-V backed to a NSX-T backed Provider Virtual Data Center. The original article describes how exactly it is accomplished and what is the impact of migrated workloads from the networking and compute perspective.

The migration tool is continually developed and additional features are added to either enhance its usability (improved roll back, simplified L2 bridging setup) or to support more use cases based on new features in VMware Cloud Director (VCD). And then there is a new assessment mode! Let me go into more details.

Directly Connected Networks

The VCD release 10.2.2 added support to use in NSX-T backed Org VDCs directly connected Organization VDC networks. Such networks are not connected to a VDC Gateway and instead are just connected directly to a port group backed external network. The typical usage is for service networks, backup networks or colocation/MPLS networks where routing via the VDC Gateway is not desired.

The migration tool now supports migration of these networks. Let me describe how it is done.

The VCD external network in NSX-V backed PVDC is port group backed. It can be backed by one or more port groups that are typically manually created VLAN port groups in vCenter Server or they can also be VXLAN backed (system admin would create NSX-V logical switch directly in NSX-V and then use its DVS port groups for the external network). The system administrator then can create in the Org VDC a directly connected network that is connected to this external network. It inherits its parent’s IPAM (subnet, IP pools) and when tenant connects a VM to it it is just wired to the backing port group.

The migration tool first detects if the migrated Org VDC direct network is connected to an external network that is also used by other VDCs and based on that behaves differently.

Colocation / MPLS use case

If the external network is not used by any other Org VDC and the backing port group(s) is VLAN type (if more port groups are used they must have the same VLAN), then it will create in NSX-T logical segment in VLAN transport zone (specified in the YAML input spec) and import it to the target Org VDC as imported network. The reason why direct connection to external network is not used is to limit the external network sprawl as the import network feature perfectly matches the original use case intent. After the migration the source external network is not removed automatically and the system administrator should clean them up including the vCenter backing port groups at their convenience.

Note that no bridging is performed between the source and target network as it is expected the VLAN is trunked across source and target environments.

The diagram below shows the source Org VDC on the left and the target one on the right.

Service Network Use Case

If the external network is used by other Org VDCs, the import VLAN segment method cannot be used as each imported Org VDC network must be backed by its own logical segment and has its own IPAM (subnet, pool). In this case the tool will just create directly connected Org VDC network in the target VDC connected to the same external network as the source. This requires that the external network is scoped to the target PVDC – if the target PVDC is using different virtual switch you will need first to create regular VLAN backed port group there and then add it to the external network (API only currently). Also only VLAN backed port group can be used as no bridging is performed for such networks.

Assessment Mode

The other big feature is the assessment mode. The main driver for this feature is to enable service providers to see how much ready their environment is for the NSX-V to T migration and how much redisign will be needed. The assessment can be triggered against VCD 10.0, 10.1 or 10.2 environments and only requires VCD API access (the environment does not yet need to be prepared for NSX-T).

The tool will during the assessment check all or specified subset of NSX-V backed Org VDCs and assess every feature used there that impacts its migration viability. Then it will provide detailed and summarized report where you can see what ratio of the environment *could* be migrated (once upgraded to the latest VCD 10.2.2). This is provided in Org VDC, VM and used RAM units.

The picture below shows example of the summary report:

Note that if there is one vApp in a particular Org VDC that cannot be migrated, the whole Org VDC is counted as not possible to migrate (in all metrics VM and RAM). Some features are categorized as blocking – they are simple not supported by either NSX-T backed Org VDC or the migration tool (yet), but some issues can be mitigated/fixed (see the remediation recommendations in the user guide).


As mentioned the migration tool is continuosly developed and improved. Together with the next VMware Cloud Director version we can expect additional coverage of currently unsupported features. Especially the shared network support is high on the radar.

18 thoughts on “How to Migrate VMware Cloud Director from NSX-V to NSX-T (part 2)

  1. Hello,

    Please share your experience. How long was the downtime for North-South connectivity during the migration of a simple tenant with several VMs and two OrgVDC routed networks.

      1. That was me 😉

        I have one more question. Is OSPF going to be supported by “VMware NSX Migration for VMware Cloud Director” tool? if so, then when(approximately)?

  2. That was me 😉

    I have one more question. Is OSPF going to be supported by “VMware NSX Migration for VMware Cloud Director” tool? if so, then when(approximately)?

  3. Hello, then im trying to migrate from V to T Orgs with direct vlan im getting error, that there is no vlan
    Validating Source OrgVDC Direct networks | The external network – vlan_3000 used in the network – vlan_3000 must be scoped to Target provider VDC – vCloud

    I have created Dummy-Org and vDC there i add same vlans witch i want to migrate
    External network VLAN backed, used by multiple direct Org VDC networks

    vCD version 10.3.1, migration tool 1.3.1
    Does anyone facing same issue ?

    1. Is the port group backing the external network vlan_3000 accessible from the target PVDC? If not, you will need to extend the external network (increase its scope).

      1. My NSX-T organization sees all vlans, i checked in provider vDC > vCloudNST > external networks.. They are same as on NSX-V org..

          1. SR: 22292042401 and support already raised it to problem, waiting for workaround and confirmed it should be fixed in next release.

  4. Hi Tom,

    Could you please explain what it exactly means “the external network is scoped to the target PVDC”

    I am trying to migrate vdc with direct connected network but I am getting following error.

    “Failed to move vApp – fw-314a4885-7f9d-4cf0-8431-a82cb73704e9 with errors Bad request: Specified parent network is invalid. Either it is inaccessible in the VDC or it is not part of the correct organization”

    Probably I am missing something.


      1. Just to be sure

        On source pvdc I have external network with backing type Distributed Port Group
        On target pvdc i have to add same external network with backing type DGP.

        If I will have same networks backed by port group it shoul be ok ?
        Now my external networks in target pvdc are backing type NSX-T Segment.


  5. Hi Tom,

    We’re using Vcloud for years now without NSX-V at all, only with “old-school” external networks VLAN backed. We’re now moving to SDN and we setup everything around NSX-T, it work great. Now, we’re desperatly looking for a solution to “link” that NSX-T with our existing PVDC, but it seems there’s no way to do that (waiting for ingineering confirmation)
    We added in VCloud NSX-T Manager, created the Geneve Pool, added the T0 but no way to add Edge Gateway to customers since our PVDC isn’t linked with the historical PVDC.
    I browsed API, but no method seems to link PVDC with a NSX-T Manager.
    Do you know any way to perform that ?

    Thanks !

  6. Hello Tom!
    Please give me a hand with following issue. I’m trying to migrate from V to T my orgvdc and using last version of Migration tool 1.3.2. Cloud Director’s version is 10.3.2.
    it seems to be ok, but when I do clean up proccess I have got a error at last step of the proccess like this:

    2022-05-06 16:25:45,126 [vcdNSXMigratorCleanup]:[run]:162 [INFO] [OlgaV]| Deleting the source Org VDC Edge Gateway.
    2022-05-06 16:25:55,973 [vcdNSXMigratorCleanup]:[run]:166 [INFO] [OlgaV]| Deleting the source Org VDC.
    2022-05-06 16:26:06,289 [vcdNSXMigratorCleanup]:[run]:170 [INFO] [OlgaV]| Renaming the target Org VDC networks
    2022-05-06 16:26:17,910 [vcdNSXMigratorCleanup]:[run]:174 [INFO] [OlgaV]| Renaming target Org VDC.
    2022-05-06 16:26:28,316 [vcdNSXMigratorCleanup]:[run]:199 [INFO] [OlgaV]| Updating the source External network.
    2022-05-06 16:26:38,790 [vcdNSXMigratorCleanup]:[run]:204 [INFO] [OlgaV]| Syncing DC Groups created
    2022-05-06 16:26:38,837 [vcdNSXMigratorCleanup]:[run]:215 [ERROR] [OlgaV]| Traceback (most recent call last):
    File “src\”, line 205, in run
    File “src\core\vcd\”, line 53, in inner
    File “src\core\vcd\”, line 3673, in syncOrgVDCGroup
    UnboundLocalError: local variable ‘response’ referenced before assignment

    2022-05-06 16:26:38,837 [vcdNSXMigrator]:[run]:1037 [ERROR] [MainThread]| VCD V2T Migration Tool Failed, Please Check the logs for the exceptions
    Traceback (most recent call last):
    File “src\”, line 1011, in run
    File “src\”, line 811, in runCleanup
    File “src\commonUtils\”, line 175, in waitForThreadToComplete
    Exception: VCD V2T Migration Tool Failed, Please Check the logs for the exceptions
    2022-05-06 16:26:38,852 [vcdNSXMigrator]:[run]:1038 [CRITICAL] [MainThread]| VCD V2T Migration Tool failed due to errors. For more details, please refer main log file C:\misc\VMware\NSX\VMware-NSX-Migration-for-VMware-Cloud-Director-1.3.2\logs\VCD-NSX-Migrator-cleanup-06-05-2022-16-25-17.log

    Is it critical error?
    What can be resolve this issue?


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

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