Tech blog

Vcloud availability

Pyxis Comunicación

Tuesday June 16th, 2020


In this new blog post we are going to show the results and conclusions of our tests on virtual machine migration and replication functionalities with vCloud Availability, for hybrid cloud.


This article is intended for administrators of cloud organizations (or tenants) based on vCloud Director, whom we’ll call OrgAdmins.

We will assume that OrgAdmin is also responsible for managing the rest of the company’s IT infrastructure.

In the hybrid cloud concept, a company runs applications in both public and private clouds, understanding public or private depending on whether or not the infrastructure is shared with other companies.

A basic functionality of hybrid cloud is to be able to migrate an application between clouds, with the least possible unavailability. Typical use cases are dealing with disaster recovery scenarios, or migrating applications across clouds to meet unexpected demand.

vCloud Availability (vCav for short) enables you to migrate or replicate virtual machines and vApps between clouds based on vCloud Director; or between vCloud Director and vSphere.

Once vCav is deployed and configured, it works as a plug-in in the HTML5 interfaces of vCloud Director or vCenter, allowing the OrgAdmin to self-manage the migration and replication processes. At high level it looks like the diagram below:

High-level component diagram in the case of migrations from on-premises to cloud

CAs we mentioned earlier, it is also possible to integrate two cloud providers with each other using vCloud Availability, so that an OrgAdmin that has vCloud Director organizations on both cloud providers can migrate virtual machines between those providers, without additional third-party intervention. See following diagram:

High-level component diagram in the case of cloud-to-cloud migrations.

This article is not intended to be a step-by-step on Availability configuration, but to show some tests developed and their results.


Some thoughts on using vCloud Availability for hybrid cloud migrations:

– The unavailability caused by a migration and its respective rollback is drastically reduced. In our tests it was 10 minutes or less rollback plus migration.

– The migration / replication tasks and their respective rollbacks are self-managed by the OrgAdmin.

– In the case of on-premises migrations to vCloud Director, it is relatively simple to configure from the on-premises site side.

– In the case of migrations between vCloud Directors, it does not require the deployment of any additional component by the OrgAdmin.

– The client does not have to pay for any additional licensing.

– Customer must use vCenter 5.5 onwards to use Availability 3.x

– To use all the functionalities, the customer must have vCenter 6.5 U2 onwards.

We run these tests and these are the results:

Test Expected result Obtained result
Execute a migration of a virtual machine, and its return, 100% self-managed by OrgAdmin. It is possible to run a migration and roll back using self-service tools, without any intervention from the vendor or third parties. Success. The migration and rollback were run using the vCloud Director tenant management interface exclusively.
Take the time it takes to activate the replica and deactivate the origin, and vice versa. Reduce unavailability times to an order of minutes. Success. 5 minutes or less between shutdown of the source virtual machine, and power on at the destination site.
Review encryption of the connection for data passage between the on-premises site and the cloud. Data traffic between on-premises and cloud is encrypted. The traffic is encrypted using HTTPS.


Every OrgAdmin that wants to migrate the on-premises infrastructure of their company to the cloud, has the challenge of achieving it in the shortest possible time, minimizing the risk of impact on the business.

Here we assess how vCloud Availability can mitigate some of those risks.

We take into account five basic attributes of any solution, such as performance, availability, recoverability, security and manageability.

Based on this, we scored the risks perceived by clients at different points in the migration processes to the cloud, and possible mitigations:

1. What if the performance of the cloud is not better or equal to that of on-premises infrastructure? (Performance)

Correctly size the allocation of cloud resources using objective metrics.

While VMware vCloud Availability does not improve cloud performance per se, it can help by rapidly migrating from cloud to on-premises or vice versa, in a fully self-managed way.

2. Will the cloud I’m migrating to have the same or better availability than on-premises infrastructure? (Availability)

While vCloud Availability does not directly affect platform availability per se, creating replicas of virtual machines between two sites can improve the availability of a given solution.

3. How do I reduce the unavailability of solutions during the migration process? (Availability).

In large-scale migrations, executing the migration of each component of each application can cause service losses (scheduled or not) of several hours, without having potentially dependent tasks on third parties such as moving physical media. vCloud Availability allows migrations without physical media transport, in the best case it can reduce the downtime to what it takes to shut down the VM at the source site and turn it on at the destination site.

4. How do I go back in case I want to go back to my on-premise platform? (Recoverability)

As we mentioned before, vCloud Availability allows total self-management regarding migrations (or going back from them), without the intervention of third parties.

5. How does the migration, once completed, affect my backup and recovery processes? (Recoverability)

The OrgAdmin must plan its backup and recovery methods at the vCloud Director site.

Vcloud Availability allows replicating virtual machines between two virtual data centers (VDCs) of the same cloud based on vCloud Director, so it could be used as a replication method.

6. What happens to the security of my data during and after the migration process? (Security)

By using vCloud Availability, you can avoid moving physical media between sites as Availability uses an encrypted connection between the two sites to transfer the data.

7. How do I manage the migration process, from a technical point of view? (Administrability).

With vCloud Availability, the customer can self-manage the migration and rollback of their virtual machines, between their on-premises site and the cloud, using the same HTML5 management interface as vCloud Director.

For testing purposes, we can group points 1,4,5,7 in one test, and points 2 and 3 in another.

High-level component diagram in the case of migrations from on-premises to cloud

As we mentioned earlier, it is also possible to integrate two cloud providers with each other using vCloud Availability, so that an OrgAdmin that has vCloud Director organizations on both cloud providers can migrate virtual machines between those providers, without additional third-party intervention. See following diagram:

High-level component diagram in the case of cloud-to-cloud migrations.


Before we talk about the test results, let’s talk a bit about the architecture of vCloud Availability from an OrgAdmin point of view.

In this section we assume that the cloud provider uses vCloud Director and also already has vCav implemented.

The appliance for tenant can be downloaded from the VMware website, and the necessary URLs and connectivity details can be provided by the cloud provider.

An additional authorization may be required from the cloud provider to use this service, but that will depend on the provider’s business policies.

In summary, the OrgAdmin must deploy an appliance, to which the services must be configured so that it can connect to the cloud provider.

vCloud Availability at the application level consists of three services:


-Establish the SSL VPN tunnel between sites


– Generates replication and migration traffic, copying virtual machine data and redirecting it to the destination site using an encrypted connection to the Tunnel service.

Cloud Management

– Availability appliance management interface service. When the site has vCloud Director, it integrates with the Director HTML5 interface.

vCloud Availability has two versions of the appliance:

Tenant – for sites with vCenter.

-All services are concentrated in one appliance.

-This is the appliance that OrgAdmin deploys in the on-premise site.

Service provider – for sites with vCloud Director.

-These appliances are deployed one-time by cloud providers and are not managed or configured by OrgAdmin.

Below is a high-level component diagram, with the different services and connectivity of the Tenant appliance:

High-level vCloud Availability architecture. VMware.

VCloud Availability architecture on the on-premises site. VMware


We deployed a lab using nested virtualization on top of vCloud Director.

We will not go into detail about the lab deployment procedure, as we follow the standard procedures of the VMware documentation for all products.

In this laboratory we are going to simulate two sites:

Site A: vCloud Director 9.5 provider, with a cluster based on vCenter 6.5 U3
Site B – Customer’s on-premises site, with a vCenter 6.5 U3 cluster

See the following diagram of laboratory components:

High-level diagram of laboratory components.



Execute a migration and rollback of a virtual machine without third-party intervention.

This is not a detailed step-by-step, as the purpose is rather to show the result and how they are appreciated

Once Availability is installed and configured on both sites, using the vCloud Director HTML5 interface, it is possible to run a migration from an on-premises machine to the cloud (see next screenshot).

En este caso, c01-vc03 es nuestro ‘Sitio A’

After that, we can configure the replica, which can be seen in this way in the following image. Note that Availability changes some machine names when it replicates, adding a suffix to them.

Replication view from on-premises to cloud

After the migration is executed, the machine can be seen in the virtual datacenter of the destination cloud, as in the following image:

Detalles de la VM migrada

Testing the reversal of migration

We see that it is first necessary to do a ‘reverse’, so that the flow of data replication changes direction. After this we can see that the type of replication appears as ‘Outgoing Replications’ → ‘to On-Prem’

After running the wizard to do the ‘Migrate’, we see the VM turned on again in the vCenter on-premise. The following image shows the VM imported back into vCenter.

Take the time it takes to activate the replica and deactivate the origin, and vice versa.

The tests were done from a fresh installation of CentOS 8, with 4GB RAM, 2 vCPUs and 16GB of RAM, virtual hardware version 10.

During both tests, the virtual machine is under load less than 10% of CPU and RAM, and with a negligible amount of IOPS.

Also, notice that in our lab, ‘Internet’ between the two sites was actually a LAN.

In our lab, migrating a VM took about 5 minutes, counting from shutdown at source to power on at destination.

The return process (cloud to on-premise), took approximately 5 minutes.

Examples of times since vCav shuts down the VM at the on-premises site, and powers it up at the cloud site, viewed from vCenter:

Revisar cifrado de la conexión para pasaje de datos entre el sitio on-premise y la nube.

Las conexiones entre sitios son cifradas usando el protocolo HTTPS. En caso de querer cambiar los métodos de cifrado poniendo más restricciones sobre los algoritmos de cifrado, basta con poner proxies reversos entre los appliances y el firewall de borde.


Encontramos satisfactorio el uso de vCloud Availability para ejecutar migraciones y réplicas de máquinas virtuales entre sitios. (ver la tabla que está en el resumen de este artículo).

Opino que un OrgAdmin no precisa apoyo significativo para migrar máquinas virtuales entre nubes una vez configurado el appliance de vCav. Es posible que el OrgAdmin, al desplegar el appliance de vCav precise soporte. Pero en ambos casos, pienso que una documentación breve y concisa sobre despliegue y uso de vCav por parte del proveedor de la nube cubrirá la mayor parte de las dudas.

Por otro lado, el cliente debería actualizar su sitio para al menos vCenter 5.5, o vCenter 6.5 U2 si quiere visualizar el plugin en la interfaz de vCenter. Esto no es imprescindible para operar con vCav a través de la interfaz HTML5 de vCloud Director.


Al equipo de Research de Pyxis por coordinar y ejecutar las pruebas de la solución, y darme una devolución sobre la misma.

Como siempre, al equipo de Comunicación por la buena disposición a ayudarnos a que la entrada quede lo mejor posible.


Pyxis Comunicación

Tuesday June 16th, 2020

Tech blog