Setting up VMware vCloud Director 9.5 for Cross-VDC Networking

In this post, I will be reviewing the necessary steps to support Cross-VDC Networking inside of VMware vCloud Director 9.5. These are fairly straightforward since it aligns to the standard requirements set forth from Cross-vCenter NSX.


  1. Multi-Site management must be configured between the vCloud Director instances. I will try to add a post on establishing this at a later time.
  2. Ensure you have a unique vCloud Director installation ID. If you have duplicate IDs, this can lead to MAC address conflicts. Fojta did a blog post on updating your ID – please accomplish this before continuing.

Cross-vCenter NSX Configuration

vCD 9.5 does require a standard Cross-vCenter NSX configuration implemented between the resource/payload vCenters before we can do any configuration at the vCloud Director level.

There are many guides out there, but here’s a link to the official VMware documentation on setting up cross-vCenter NSX. 

This can be a single or multi-SSO domain topology. In my environment, here’s what I’ve configured between my two sites: Site-A and Site-B.

  1. From the Networking and Security plugin, I’ve assigned my Site-A NSX Manager while linking Site-B NSX Manager as the secondary instance – 
  2. From there, I need to establish my Universal Segment ID pool and Transport Zone.
  3. Keep in mind you do not want to overlap with an existing Segment ID pool, so pick a number that’s high enough (or out of reach from other pools) – 
  4. From the Transport Zone screen, I’ve created my new Transport Zone named “Universal-TZ” – 
  5. Now I’m ready to connect it to my respective clusters on Site-A and Site-B. Keep in mind I need to hit the drop down for the NSX Manager and attach the respective cluster at your secondary (or additional) location.
  6.  That’s it! Onto the next configuration which is at the vCloud Director level.

vCloud Director Initial Provider Setup

In this step, we need to assign the correlated NSX Manager to each vCenter instance that’s participating in the Cross-VDC networking solution. I will be showing how I’ve done this for my two sites, Site-A and Site-B, while establishing a fault domain.

  1. From my Site-A, navigate to System -> Manage & Monitor -> vSphere Resources -> vCenters – 
  2. We are going to right click, go to Properties of this vCenter – 
  3. From there, we need to go the NSX Manager tab. This is where we populate the following:
    1. Host/IP of NSX Manager
    2. Admin username
    3. Admin password
    4. Control VM Resource Pool vCenter Path – this can be either the MOref object id OR the ‘Cluster/RP’ path – I chose the former.
    5. Control VM Datastore Name – full name
    6. Control VM Management Interface Name – again, full name
    7. Network Provider Scope – now this is where we establish a fault domain. This Network Provider Scope could cover one or many vCenters in a single vCloud Instance. However, when we establish the vdc-Group, we must have a minimum of two different/unique fault domains (or network provider scope) inside of the created vdc-Group.
  4. Now, on my Site-B, I will configure my respective properties along with a Network Provider Scope of “region-b” – 
  5. Great! Next step is to add the Universal Transport Zone as a new network pool on each vCD instance. This is purely importing the created Universal-TZ and moving on, so very easy – 
  6. That’s it – now we are ready to enable a specific orgVDC for cross-VDC networking.

Enabling an orgVDC for Cross-VDC Networking

This is a very simple process – really just enable it on a per orgVDC basis.

  1. Go to your orgVDCs and right click on the orgVDC you want to enable cross-VDC Networking on. For example, I am enabling this on my Daniel oVDC’s – 
  2. Click on the Network Pool and Services sub-tab and you’ll see a new box below the Network Pool that states ‘Enable Cross VDC Networking (Using Network Pool “<Universal-TZ-Pool>”‘ Check this box.
    1. This still allows for local oVDC network creation using the traditional network pool as stated in the screenshot above – this is not a complete conversion to the Universal Transport Zone.
  3. Now, enabling this on my Site-B – 

Permissions/Rights required for Cross-VDC Networking

As discussed in the previous blog post, there are specific rights and roles required for Cross-VDC networking that are not enabled by default for the organization administrator. Please review these before the tenant utilizes Cross-VDC networking.

Cross-VDC Networking Permissions Review

Creation of the initial Cross-VDC Group

Now we are ready to test the creation of a new Cross-VDC group.

  1. Let’s log into the Tenant UI and we should see the Datacenter Groups from the context switching menu – 
  2. Now, I can create my first Cross-VDC group and start establishing my egress points. Awesome! 

More to come here on the Cross-VDC networking capabilities within vCD 9.5 from myself, Wissam Mahmassani, and Abhinav Mishra. Thanks!


A New VMware Badge Appears: VMware Specialist – Cloud Provider 2019

Many of you may be aware of the new VMware Specialist – Cloud Provider badge. However, I am going to spend some time to highlight the effort and provide some guidance on this new badge/exam. Also, it’s officially announced with many of our other great announcements at VMware Europe!

What is it?

Well, the Specialist Cloud Provider badge is a renewed effort that the VMware Cloud Provider team is establishing a solid, fundamental certification/qualification platform for our Cloud Service Providers. This is the first step on setting a level of qualification to present solution knowledge around the VMware Cloud Provider Program (VCPP) stack and solution-set, especially VMware vCloud Director for Service Providers 9.x.

This is an online, un-proctored, exam that can be scheduled through Pearson Vue. The only prerequisite we’ve established is an active VCP certification. I was honored to be part of the team to develop this exam while Wade Holmes led the overall effort with many of my esteemed peers. It is 40 questions and you have 60 minutes for the exam.

What does it cover?

Just like with any other VMware certification – read, read, and read the blueprint: all of the answers are there. I believe the team did a great job of putting many links into this blueprint for material to prepare for. However, I’m going to highlight a few points that everyone should be aware of –

  1. This exam covers vCloud Director 9.1 functionality. Even though 9.5 is out as of this blog post, this was written when 9.1 was the current release.
  2. Sections 3, 5, and 6, are not present on this exam. Therefore, there are no troubleshooting questions. Be prepared to focus on core fundamentals and conceptual features of vCD.
  3. vCloud Availability for Cloud-to-Cloud 1.5 is present also on this exam, there is no vCloud Availability for DR questions. Moreover, vCD Extender is also present.

How can I prepare?

This answer is simple – work with vCD and the VCPP stack and you’re golden! 🙂

On a serious note, there’s a lot of great material on the blueprint, but we have two great VMware Education courses on vCloud Director:

VMware vCloud Director Fundamentals [V8.x] – this is an on-demand course that goes over core fundamentals of vCD. While it is dated for 8.x, it is very applicable. This is a self-paced course and can be done in about 3 hours.

VMware vCloud Director: Install, Configure, Manage [V9.x] – if you are very new to vCD, I recommend taking this course after the Fundamentals course. This provides a comprehensive experience (including lab time) of building out a vCD environment. This can be done online or in-person.

Read the documentation – we have a mess of many different docs we’ve referenced. Also, check out the many YouTube videos we have under our Cloud Provider page! 

Final thoughts

I believe this is a very fair exam for individuals that work with the VMware Cloud Provider solution set. The questions and concepts focus on the value and core fundamentals.

I’ve been receiving a lot of great and positive feedback, which is excellent. This was my first exam creation experience and I truly enjoyed the process, and look forward to the next step for our VMware Cloud Providers. If you’re at VMworld Europe, please don’t hesitate to contact me to meet up! Thank you.


Managing access to the VMware vCloud Availability for Cloud-to-Cloud Plugin to vCloud Director 9.5

With C2C 1.5, a new plugin was introduced inside of the vCloud Director 9.x context switching menu. By default, all organizations and org admins receive this plugin once C2C is installed. What if we wanted to restrict/control access and mask this from specific tenants? Well, I plan on walking through how this is done using the new /cloudapi inside of 9.5.

Recently, I ran into a situation where my Cloud-to-Cloud plugin was not populating in the vCD context menu for my organizations, however, I saw it in the sysadmin view –

So, this led me to investigate further and discover the full capacity of the plugin management from the new vCloud Director 9.5 API (with the help of Jeff Moroski)

With vCD 9.5, we introduced the use of bearer tokens for authentication. Tomas Fojta did a great job of writing up a how-to guide on using bearer tokens inside of Postman while embedding the token after login.

First off, how did I resolve the above problem? Well, it turned out that it was not published out to any organization. Let’s walk through the API and discuss how one can control access to the plugin.


First off, POST to your vCD instance to grab the access token –


From there, I’m ready to run a GET to see what extensions are registered to this vCD instance (remember, uncheck the Accept/XML header since this is JSON) –


We can see my plugin has a identifier associated of –

"id": "urn:vcloud:uiPlugin:c450bdf8-764f-4631-a319-1c849873c176",

So, let’s see which tenants have access to this now. Here’s my GET API string –


Now, in my above issue, I had nothing in the output body. Therefore, Jeff stated that I needed to append “publishAll” to propagate to all tenants. Great!

Let’s go ahead and remove access to the “Daniel” organization for C2C. Right now, I see this in my UI –

This requires a POST command with the JSON body that has the “Daniel” organization inside of it –


        "name": "Daniel",
        "id": "urn:vcloud:org:aa663210-b11f-4c14-8dca-1efab8dec429"

I received a 200 OK message, so it looks like it worked, let’s go check.

A quick refresh, voila! Gone.

Again, this is a great way to verify and control the accessibility to the Availability plugin (or any vCD plugin) in vCloud Director 9.5. Cheers!


Migrate VMs and Networking to vCloud Director – Video Walkthrough

I wanted to provide a quick walkthrough on how easy it is to import a VM (or adopt a VM) into a tenant organization for vCloud Director.

Tomas Fojta covers a lot of great detail on when this was introduced in vCD 8.20 here. 

In this video, I go through and show how I moved a tenant workload (DanielApp) along with a network to vCloud Director and NSX.

While this does require a stepped process, it’s a pretty seamless process.

Migration Steps:

  1. Move the routing interface from the current physical underlay to the NSX Edge inside of the vCloud Director tenant organization (DCP-Edge-01)
  2. Switch over the VMNIC for the workloads to the logical switch presented by DCP-Edge-01
  3. Drag the VM to the orgVDC resource pool that’s provisioned by vCloud Director. Done!

Note 1 and 2 do require some level of coordination with your network team with a brief maintenance window (route changes and validation). Moreover, the important distinction is we are allowing a tenant to utilize NSX functionality alongside vCloud Director.

Step 3 is the easiest. vCloud Director does all of the work and shows it in the UI without any further intervention. This is a great feature that demonstrates vCD can be utilized for existing tenant workloads that may be in a “naked” vCenter environment (or utilizing an existing CMP they are moving away from).

Anyway, here’s the video I created that shows me moving DanielApp to vCloud Director under my “Daniel” organization.


Last bit I’ll leave you with – while it’s great to migrate both the network and to vCD, this may not be possible based on use case. Other migration method could be exposing the existing distributed virtual portgroup as a vCD External Network to the pVDC, then the oVDC. Then it’s as simple as just dragging in the VM(s) to the resource pool.

However, I do lose any self-service and NSX functionality, which could include overlapping networks when I scale out tenants.

Happy migrating!