vCloud Availability introduces a unified architecture for a disaster recovery and migration. With vCloud Availability service providers and their tenants can migrate and protect vApps and virtual machines:

  • From an on-premises vCenter Server site to a vCloud Director site
  • From a vCloud Director site to an on-premises vCenter Server site
  • From one vCloud Director site to another vCloud Director site


According to VMware official vCloud Availability 3.5 (vCAV) documentation here, vCAV 3.5 provides the following capability:

“Replication and recovery of vApps and virtual machines between vCloud Director sites.”

Today I’m going to test the vCAV Cloud to Cloud DR functionality and share how to use it from a Tenant’s perspective.

The vCloud Availability Deployment Architecture in the Cloud in the Cloud Service Provider side is as below:architecture

As a Tenant, your subscribe DRaaS from your cloud service provider, they then based on your agreed SLA to define your DR replication policies and pair the destination cloud site for you.

Assume you are the “TenantA” cloud administrator in vCloud Director site, you can access the vCloud Availability Portal from the vCloud Director tenant portal, also you can manage cloud and disaster recovery environments from a single user interface which simplifies the management operations.

Example here is that your company (TenantA) subscribed the DRaaS solution from VMware VCPP partner, you’ll get the DR environment (under the same organization name or different one, here we use “TenantADR” for example) on the second vCloud Director site shown in the right-hand side in the following diagram. testing architecture.png

Now, let’s get started to configure the Cloud to Cloud DR replications and you’ll see how easy it is to implement DR solution for your company.

Log In by Using the VMware vCloud Director Tenant Portal

you access the vCloud Availability Portal from the vCloud Director tenant portal, you can manage cloud and disaster recovery environments from a single user interface which simplifies the management operations.

You login as user with “Organization Administrator” role to vCloud Director to operate workloads enabled for replications from production vCloud Director sites, DP-POD; in this environment, you have one vApp, ERP-2, which contains three VMs, Web-2, AP-2 and DB-2.



Open the vCloud Availability Portal, by selecting “vCloud Availability” from the main menu.


Authenticate to Remote Sites as a Tenant

In the left pane, click Sites.vCav2.png

On the Cloud sites page, select the remote site (Site-B) you want to authenticate to and click “Login”.


In the Log In window, enter the remote site “Organization Administrator” credentials, and click “Login”.


You’ll see the ‘Management Session” of the cloud site turned green status.


Replication Policies

To control the replication settings of VMware vCloud Director in your organization, your cloud service provider should have already created and assigned a “replication policy” to your organization. Replication policy defines the following replication options:

  • whether to allow incoming and outgoing replications
  • maximum number of virtual machines replications
  • maximum number of retained instances per replication
  • minimum allowed Recovery Point Objective

P.S: You won’t see this in your GUI since this should be done by your cloud service provider.


Create a Protection or Migration

In the left pane, choose a replication direction: under “Outgoing Replications” click “to Cloud”:


Replication Types

When vCloud Availability is paired with another DR site, tenants (and service providers under managed service contract) can:

  • Protecting a vApp or a virtual machine from one organization to another keeps the workload running in the source site.
  • Migrating a vApp or a virtual machine to a remote organization runs the workload in the destination site.

Here we want to protect a vApp, so we click the vApp button, click “New Protection”:


    Follow the prompts of the New Replication wizard, select a vApp, ERP-2, this is the vAPP we want to protect in local site:


    Select Target Site, Site-B:


    Select TenantADR-oVDC as the Target VDC, this is where we want ERP-2 vApp to reside in the remote DR site.


    On the “Protection Settings” page, select the settings for the replication, and click “Next”.

    You can also optionally change the RPO, Storage policy, Retention policy, Enable quiesce, seed VMs disk mapping, VM exclude disks, etc., settings.


    On the Ready to Complete page, verify that the configuration settings are correct and click Finish.


    In the Outgoing Replications to Cloud windows, you’ll see the replication task is running in progress.


    In the Site-A vCloud Availability Topology GUI, you can see the overall cloud to cloud replications task status.


    In the remote DR site, we login as tenant TenantADR user, we can see the corresponding Incoming vApp replications task status also showing green OK status.


    In Site-B, if all the VMs’ disks have been synchronized between clouds, we can see the ERP-2 vApp Replication state is turned into “Healthy” green status.


    Also we can check all the replication tasks’ status from Site-B’s vCloud Availability GUI, in the “Replication Tasks” section:


    Now we have successfully configured the ERP-2 vApp to have it protected and replicated to remote vCloud Director DR site, this vAPP is ready for failover!


    This wraps up my first part series on using vCloud Availability 3.5 from tenant’s perspective, in the next part, we’ll see how to actually run the testing failover, failover and migrate the workload to the vCloud Director DR site. Feel free to reach out to me on Twitter if you have any additional questions or comments. Thanks for the read!



    • “Using VMware vCloud Availability” VMware official documentation is here.
    • You can check out “What’s New with VMware vCloud Availability 3.5” by Daniel Paluszek here.
    • Special thanks to Daniel Paluszek, he’s generous enough to share his lab environment with me for this work.