How does VMware vCloud Availability for Cloud-to-Cloud 1.5 interoperate with vCD Cross-VDC Networking?

I get this question quite a bit due to the new vCloud Director 9.5 Cross-VDC networking functionality – does vCloud Availability for Cloud-to-Cloud 1.5 (C2C) work with stretched networking inside of Cross-VDC networking?

The answer is: yes!

This is another great addition for recoverability considerations as one could fail over between vCloud Director instances without modifying the guest OS IP address. Furthermore, based on the application architecture, one could have active-active applications and ensure replication/failover in the event of a disaster.

Let’s go through my example high-level design I’ve worked up in my lab –

Example Cross-VDC setup with vCloud Availability for Cloud-to-Cloud 1.5

In the above diagram, we can see I have two active vCloud Director instances, Site-A and Site-B. I have two organizations, “Daniel” that resides in Site-A along with “Daniel-B” that resides in Site-B.

C2C is deployed on each site in the combined model and I have multi-site pairing completed so I can easily manage this between my two sites –

Within my Cross-VDC networking setup, I currently have my active egress setup to Site-A as depicted in the diagram above.

Last of all, I ran a protected workflow from Site-A to Site-B for my Stretched-vApp-VM –

From there, one can either migrate or failover the workload and without any guest OS IP changes. I am going to do a video shortly, but here’s a short GIF I created that shows the ease of use of failing over between my Site-A and Site-B –


After failover, I can then access Stretched-vApp-VM from the new NAT address on Site-B.

An Organization Administrator could also configure active/active or active/passive egress points for additional resiliency. This provides further capability inside of vCloud Director, especially with stretched networking and a complementary availability solution.



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. Moreover, C2C will also upgrade any existing (older) plugins and register the new one insie of vCD (or if the plugin is missing for some reason, it will register and publish to all). 

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 was in my lab environment researching the ability to control access to the Availability plugin. 

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 control accessibility to the Availability plugin? 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 –


As shown above, I can see all of my tenants have access to the Availability plugin. If I needed to force publish to all (for any other type of plugin), Jeff stated that I needed to append “publishAll” to propagate to all tenants.

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!


VMware vCloud Availability for Cloud to Cloud 1.5 is announced! What’s New?

I am excited to announce that vCloud Availability for Cloud to Cloud 1.5 (vCAv-C2C) will be released for VMware Cloud Providers at end of September. This has been a long and fruitful journey between strategic design partners and our internal teams.

In this post, I will review what’s new inside of vCloud Availability for Cloud to Cloud 1.5.

Don’t know what vCloud Availability for Cloud to Cloud is – don’t worry, check out this intro post!

To start, our lightboard video as an intro to C2C and what’s new with 1.5 –

A quick summary of what I’ll be discussing:

    1. Enterprise Scale
    2. Service Provider Policies for Offer Management
    3. Seamless and unified experience with integration to vCloud Director
    4. vRealize Orchestrator Integration (Compatible with C2C 1.0)
    5. vRealize Operations Day 2 Monitoring Pack (Compatible with C2C 1.0)
    6. Public API
    7. Enhanced Usage Reporting


Let’s talk about scalability for C2C for a moment. The BU has certified the following for C2C 1.5 –

  • 110 concurrent failover protections
  • Over 3,000 active protections across 100 tenants. This is a variable number as it will depend on the number of active tenants along with protected operations. However, in discussing this with Engineering, we’ve seen 4,000 VM’s protected by vCAv-C2C.
  • Scale up to 7 tested replication instances.

Again, this has been an important enhancement as we have received multiple requests regarding scale. I would also say this is the maximum configuration we’ve tested so far. This does not mean our technology is limited to these numbers. If there’s something specific you’d like to see, please talk to your VMware Cloud Provider field team.


With C2C 1.5, Cloud Service Providers (CSPs) can now manage access control for vCloud Availability – Cloud to Cloud DR on per tenant organization basis. By default, all tenant organizations are disabled and CSPs can choose to enable C2C DR service for one or many organizations. This allows CSPs to deliver Cloud to Cloud DR as a value-added service to their tenants.

As we can see from above, I have the Default Policy along with “Org1 Policy” that I created that I applied to my Org1 organization.

So, if an org that has not been whitelisted for Cloud to Cloud usage, what do they see? Well, they would get an error when attempting outgoing or incoming replications such as the below:

In addition to white-listing organizations, C2C DR also allows a CSP to create and assign new policies for select organization, thus giving them an opportunity for tiered offering and providing them better control on their capacity management. Following new policies have been added:

  1. Limit the maximum number of outgoing and/or incoming replications per organization
  2. Limited maximum number of replicated VM’s per organization
  3. Limited maximum number snapshots created by VM
  4. Allow to set lower limit on RPO per organization

Again, providing a granular application to specific orgs. We could create multiple policies and have different policies associated with each of them.

Last of all, we can see the compliance state on each org –

Integrated vCD UI

While using the vCloud Director portal extensibility capability, the team has now introduced an integrated C2C plugin for vCD!

Once C2C is deployed and registered to your vCD instance, we will see the Availability link in the context switching menu (or what we like to call the hamburger menu).

From there, the tenant user can navigate to C2C from the vCD interface, thus providing fully integrated and seamless experience and alleviating need of any console hopping.

vRealize Orchestrator Integration

While this is something that will be released post version 1.5, this is an awesome addition as now we can provide unique workflows on a per tenant/use-case basis in an automated fashion. Now, combine this with the power of the new vRO/vCD integration within the Content Library!

From vRO, we can see we have a new section vCloud Availability –

The first thing we would need to do is connect to each respective site –

From here, we have multiple options available that were built by our team, including IP address change after failover:

vRealize Operations Day 2 Monitoring Pack

We are now introducing a management pack for vRealize Operations. This will be also released post version 1.5, however, this will allow the Provider team to have a single monitoring and analytics tool for providing vCAv-C2C statistics and rollups of the environment.

There a few out of the box dashboards available –

From here, we can get a picture of what’s going on from an operational perspective, including any RPO violations set by vCAv policies. While my test environment is clean, this gives you an idea of what to expect.

As a last note – vRealize Orchestrator and vRealize Operations plug-in have their own release cycles and would typically lag a little bit behind the core Cloud to Cloud releases. The vRO and vROPs plug-ins for Cloud to Cloud are currently supported only for C2C 1.0 release). Please reach out to your VMware Cloud Provider field team if you’d like to discuss these further.

Public API

There is now an API available for C2C operations. Public API are generated through Swagger which is quickly becoming a de-facto standard for generating APIs. This allows for additional extensibility to Providers on managing C2C operations along with potential opportunity to integrate their Cloud to Cloud DR use-cases into their own Cloud management portal if this wish to do so.

Start off by going to the API documentation here

The steps to set up the Swagger client is fairly easy. I was able to do this in a Windows environment by using the PowerShell commands.

Start with downloading the JSON file –

Then, download the swagger-codegen client and run the generate command to generate the Java client –

And now the build is ready for .java files with the C2C parameters. I hope to have time to play around with this further.

Enhanced Usage Reporting

While Usage Meter integration is underway, we can pull reports from the C2C appliances by logging into the application console – documentation is here. 

We start by SSH’ing or opening the console to the C2C appliance. From there, we need to authenticate again in the h4 context so we can type in the ‘usage-report’ command –

Now, I am able to run ‘usage-report’ and find out my usage –

Again, a lot of great content and additions to C2C 1.5. Please check it out!


VMware vCloud Availability for Cloud-to-Cloud DR – Pairing and Usability (2 of 2)

Continuation of VMware vCloud Availability for Cloud-to-Cloud DR – Pairing and Usability (1 of 2)

This post covers pairing and usability of VMware vCloud Availability for Cloud-to-Cloud DR.

Previous blog posts:

Blog Post – what is vCloud Availability for Cloud-to-Cloud DR? 

Blog Post – vCloud Availability for Cloud-to-Cloud DR – Installation and Setup

  1. Part 2:
    1. Initial authentication between the two sites
    2. Migrating a workload in the same site
    3. Protecting a workload between two sites
    4. Testing the protected workload
    5. Edit Options
    6. Failing Over

Initial authentication between the two sites

  1. This is pretty simple and very similar (if not exactly) like vCAv-DR2C. Go to Paired Clouds -> click the actions button to authenticate on the paired remote site. For me, this is SiteB. 
  2. We need to provide the organization name, the username of the org admin, and password. Note this must be an organization admin for pairing. 
  3. Complete! 
  4. Now, I can do the same on my second site, SiteB. 

Migrating a workload in the same site

  1. So let’s work through a use case where I want to migrate a vApp or VM between two different oVDCs in the SAME vCloud Director instance. This question came up on the vExpert Slack channel and I thought this was supported, but wanted to make 100% sure. The answer is yes – fully supported. So let’s go through how I made this happen.
  2. From the DR Workloads tab, let’s click on the Discovery button – 
  3. From here, our source is going to be our same site, which is SiteA/Org1, which should show host in parenthesis. 
  4. Let’s select my test vApp, which is properly named “vApp_test” for this exercise. 
  5. Now our destination is the same vCD instance, or SiteA/Org1. Let’s select it –
  6. We can now see the other org VDC available, which is my Org1-Gold-oVDC. This is the only selection available as we cannot move it to the same oVDC and I do not have more than two oVDC’s inside of this organization. From here, we can also select the Storage Profile, Target PRO, and if we want to add in any Point-in-Time instances along with data connection type. 
  7. Once we click finish, we get our setup screen… 
  8. We can now see the vApp is being configured and in the “Protecting” status. 
  9. Complete! All green and in the “Protected” state so it’s ready for migration over to my destination oVDC. 
  10. Let’s go ahead and click Failover and get the confirmation window on what we want to do. I can select the DR Network (I didn’t set up networking for this test) and if I want to turn on the target VM. 
  11. We can now see the status has changed to “Failing Over” – 
  12. From my vCD instance, I can see the vApp being imported… 
  13. Source/Original vApp is being powered off.. 
  14. Under Tasks on the vCAv portal, I can see the migration tasks underway – 
  15. Complete! We have successfully migrated over the vApp to the new orgVDC. We also see the original/source vApp was completely powered off, or in the Stopped state. 
  16. In conclusion, very simple and intuitive to migrate between the same vCD instance. Theoretically, you could deploy this at a single site and use this for local migration.

Protecting a workload between two sites

  1. So let’s cover migration between the two sites – SiteA and SiteB. In this exercise, we will be protecting a workload in SiteB and protecting it to SiteA. This is very similar to our exercise above (migrating between the same site) while we are selecting the paired site for protection.
  2. Let’s go ahead and click on Discovery and select our source site (SiteB) – 
  3. Now we can select our vApp that we will be protecting to SiteA – 
  4. Select our destination, which mine is SiteA/Org1 – 
  5. From our final screen, we can select the appropriate oVDC, storage profile, and my target RPO. For this exercise, I’ll be adding in some Point-in-Time instances too. Click OK and let’s get to protecting…
  6. I tried to grab the transition log, but it was too fast. But I do see the initial replication succeeded along with my protected vApp showing “Protected” – awesome! 
  7. I also like the event pop up we get when something changes. We can see this in the above screenshot that shows my newest protected vApp is good to go.

Testing the protected workload

  1. Testing is the ability to bring up the protected workload at the destination site in an isolated network of your choosing – this allows the application owner to verify everything is operational and could be used for regulatory purposes too.
  2. Testing is pretty easy – it can be orchestrated from either site (source or destination) and it’s with a click of a button –
  3. We get the confirmation screen and the choice of our test network we want to utilize. Once I hit the Start button, I can see the status changes to “Failover Testing Initializing.” 
  4. On my SiteA, I can see within the logs the failover testing is underway while we have a transition of a vApp inside of SiteA – 
  5. Alright, now it shows Failover Test Ready which is great. Now, my app owner can test their app on the destination and verify functionality. 
  6. One of the nice additions is the quick launch buttons on the test workload – we can hover over the two icons and see quick launch buttons to get to each site. Very nice addition. 
  7. Finally, when our testing is done, we can click the Cleanup button to remove the test VM and go back to our normal, Protected state. Pretty straightforward. 

Edit Options on protected workload

  1. Clicking the Edit button provides us with the ability to make changes to a current protected workload –
  2. From the options pane, we can see the following – 
  3. We get our standard RPO slider – from 5 minutes to 24 hour RPO selection – while providing the ability to keep point-in-time instances for further retention.
  4. Moreover, all traffic is encrypted but we can also further optimize by compressing data. Very similar to vSphere Replication, the replicators will attempt to compress the data to minimize network traffic.
  5. Last of all, we have the ability to quiesce the operating system by using VMware Tools.

Failing Over

  1. In our last example, we will fail over my core-B vApp from SiteB to SiteA. Failover can be done from either site (especially important if I lost my source site) and very straightforward.
  2. Let’s select Failover from the UI – 
  3. As discussed before, our standard options and what network we want to select. 
  4. We can see it transitioned to Failing Over… 
  5. Voila! Failed over. Now we can click the quick launch shortcut and start doing whatever we need to do. 
  6. Another thing to note – even with a failed over workload, we can reverse the replication and reprotect it back to our original site, assuming the site is still operational. This is done by selecting the Reverse button. Now, this will show as outgoing from my SiteA to SiteB.

That’s it, folks! My hope is this was informational for any providers that are considering to utilize Cloud to Cloud for migration and DR needs for their multi-site vCloud Director environments. It’s a great tool and is very intuitive for our tenants and providers.