Protect or migrate workloads by replicating vApps or virtual machines. VMware Cloud Director Availability protects or migrates vApps and virtual machines by replicating the workload from the source site to the destination site.

The replications are incoming from source sites, or outgoing to destination sites.

Replication Types

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

In VMware Cloud Director Availability 4.1 and later, the service provider controls protections and migrations separately by using replication policies, either only incoming, or only outgoing, or both, or neither.

By default, for a newly deployed VMware Cloud Director Availability:
  • Protections are inactive in the default replication policy, both incoming and outgoing. To allow protections to or from the site, the service provider must modify the default policy. Alternatively, keep disaster recovery only for subscribers by assigning a custom policy to the organizations. For more information, see Configuring Replication Policies.
  • Migrations are active in the default replication policy, both incoming and outgoing, to allow migrating workloads for everyone.

In VMware Cloud Director Availability 4.3 and later, for replication using Data engine Classic, on start virtual machine replication when VMware Cloud Director Availability encounters a virtual machine that is already configured for replication, possibly by another replication solution, it is unconfigured first and then it is configured for replication.

Replications Use Cases

Replications support the following sources and destinations:
SDDC Solution Description
On-premises vCenter Server An on-premises SDDC, managed by VMware Cloud Director Availability On-Premises Appliance.
VMware Cloud Director A private cloud site in an on-premises SDDC, managed by Cloud Replication Management Appliance.
VMware Cloud on AWS VMC vCenter Server An SDDC in VMware Cloud on AWS, managed by VMware Cloud Director Availability On-Premises Appliance
VMware Cloud Director service A VMware Cloud Director instance in VMware Cloud on AWS, managed by Cloud Replication Management Appliance.
For information about VMware Cloud Director Availability in VMware Cloud on AWS, see Migration to VMware Cloud Director service in the Migration to VMware Cloud Director service Guide.
In the following table:
  • According to the replication type and the selected data engine:
  • No represents a non-operational use case.
  • Future represents a disabled or inactive use case that might be operational in a future version.
  • Yes represents an operational use case.
  • * Note limitations.
Destination Replication Type Selected Data Engine: Source
VMware Cloud Director vCenter Server VMC vCenter Server VMware Cloud Director service*
VMware Cloud Director Protection Classic Yes Yes Yes ** Yes **
VMC No No No No
Migration Classic Yes Yes Yes Yes
VMC No No No Yes
vCenter Server Protection Classic Yes No No Yes **
VMC No No No No
Migration Classic Yes No No Yes **
VMC Future No No Future
VMC vCenter Server Protection Classic No No No No
VMC No No No No
Migration Classic No No No No
VMC Future No No Future
VMware Cloud Director service* Protection Classic No No No No
VMC No No No No
Migration Classic No No No No
VMC Yes Yes Yes Yes
Note:

* For VMware Cloud Director service you could use either the Classic data engine or the VMC data engine but not both.

** The protection is in a single direction. The reverse workflow is not operational.

Depending on the selected data engine in VMware Cloud Director Availability, some use cases might not be operational. For example, when the VMC data engine is selected and the Classic data engine is not selected, VMware Cloud Director Availability cannot replicate between on-premises SDDCs.

For information about selecting the data engines, see Pair VMware Cloud Director Cloud Sites in the Migration to VMware Cloud Director service Guide.

Recovery Point Objective - RPO

Shorter RPO lowers the data loss during recovery, at the expense of consuming more network bandwidth for keeping the destination site replica updated and increasing the volume of event data in the vCenter Server database.

Shorter RPO requires all operations in the background to complete in shorter time periods. Reducing the RPO increases the stress for all infrastructure components and increases the demands for both the source and for the destination sites and for the connectivity between them. For information about monitoring the environment to discover possible bottlenecks and implementing infrastructure changes for optimizing the flow of the replication data traffic, see the Replication Flow document.
Target RPO of Protections
RPO is the longest tolerable time period of data loss from a protected workload.
For example, protected virtual machine with one hour RPO means that the recovered virtual machine in the destination site can incur no more than one hour of data being lost when the source site fails. In VMware Cloud Director Availability 4.3 and later, for protections the RPO selection ranges from one minute to 24 hours. With shorter RPO, an I/O intensive protected workload can cause RPO violations.
Note: Migrations RPO is 24 hours.

When each replication reaches its target RPO, in addition to updating the destination site replica the Replicator Service writes about 3800 bytes in the vCenter Server events database. For reducing the volume of event data, configure a longer RPO or limit the number of days that vCenter Server retains event data.

Quiescing

To achieve a consistent state, by quiescing the Replicator Service guarantees a failure consistency among all disks in a virtual machine.
Activate Quiesce
Activating quiescing might obtain a higher level of failure consistency among the disks belonging to a virtual machine.
The operating system of a virtual machine determines the available types of quiesce. Quiescing is available only for virtual machine operating systems that support quiescing.

Owner

The user that starts a replication becomes its owner.

After starting the replication, the system administrator can change the owner of a selected replication. Any replication started by the system administrator is not visible to the respective organization and its tenants unless the system administrator explicitly changes the replication ownership to the organization. To manage such a replication by a tenant, change the replication owner to the organization of the tenant.

As a system administrator, to change a replication owner, select the replication and click All Actions > Change Owner. In the Change Replication Owner window, select a new owner organization for the selected replications and click Apply.
  • System organization - assigns the system administrator as a replication owner. Tenants do not see replications owned by the system organization.
  • Tenant organization - assigns the organization in the destination* site as a replication owner, allowing the tenants from the destination organization to see and interact with the replication. Destination organization ownership applies both for replications from cloud sites to cloud sites and from on-premises sites to cloud sites.
* If the destination of the selected replication is an on-premises site, assigns the organization in the source site as a replication owner, allowing the tenants from the source organization to see and interact with the replication. Source organization ownership applies only for replications from cloud sites to on-premises sites.

Replication tasks initiated by the system administrator are not visible to the tenants, even after providing the organization with ownership.

Compute Policy

VMware Cloud Director Availability 4.3 allows the service providers and their tenants to select a placement compute policy for a specific cluster or host for the recovered virtual machine (VM).

Select the policy when configuring new replications or in the replication settings of an existing replication.

VDC VM Placement Policy
The placement policies represent organization VDC compute policies that define the VM-host affinity rules controlling the placement of tenant workloads on a host, group of hosts, or one or more clusters. Selecting a placement policy adds the recovery VM to a VM group in vCenter Server, where the VM groups represent the host group to which they have positive affinities. A positive affinity rule places a VM group on a specific host.
For information about creating placement policies in a provider VDC and about adding them to an organization VDC, select the VMware Cloud Director version in the following VMware Cloud Director documentation.

Replicated Workload Settings

VMware Cloud Director Availability preserves and periodically synchronizes the VMware Cloud Director settings that accompany the vApps or the virtual machines in a replication. After a successful protection or migration, VMware Cloud Director Availability reads these settings from the source site and applies them to the destination site, at the end of the replication workflow.
Table 1. Replicated vApp Settings
vApp Settings Replicated in Version 3.0 Replicated in Version 3.5 or Later
vApp Name Yes Yes
Description Yes Yes
Leases - -
Starting and Stopping VMs Configuration - -
Мetadata Yes Yes
vApp Networks - Yes
Table 2. Replicated VM Settings
VM Settings Replicated in Version 3.0 Replicated in Version 3.5 or Later
VM Name Yes Yes
Computer name Yes Yes
Description Yes Yes
Hot add settings - -
Guest OS Customization - Yes
Guest properties - Yes
Resource allocation - -
Metadata Yes Yes

Modifying the Hardware of a Source Virtual Machine While Protected by VMware Cloud Director Availability

  • Adding another virtual disk to a replicated virtual machine at the source site pauses the replication.
  • VMDK resizing with vSphere 7.0 in the source site automatically resizes the protected virtual machine disk in the destination site, retaining the replication instances.
  • Modifying the vCPU count or the RAM size of the source virtual machine replicates on RPO or on manual synchronization in the destination site.

Replicating Thin or Thick Provisioning Virtual Disks

The replicated disks provision format depends whether using replication seeding. For information about seeds, see Using Replication Seeds.
  • If not using replication seed, the replica disks are always thin provisioned.
  • If using replication seed, the replica disks depend on the seed.
    • If the replication seed is thick-provisioned, the replica disks are provisioned as thick.
    • If the replication seed is thin-provisioned, the replica disks are provisioned as thin.

Replicating Other Storage

Storage DRS (SDRS)
  • At the protected site, storage DRS is supported.
  • At the recovery site, storage DRS does not move replication files between datastores. Datastore maintenance mode, storage balancing, and IO balancing all ignore replication files. The only supported way to move the replication files between datastores is to change the storage policy.
Raw Device Mapping (RDM)
  • RDM in virtual compatibility mode can be protected.
  • RDM in physical compatibility mode is skipped from replication.
Multi-writer Disks
VMware Cloud Director Availability does not support disks in multi-wire mode.
Independent Disks
VMware Cloud Director Availability does not migrate independent disks.
Change Block Tracking (CBT)

VMware Cloud Director Availability instances are not compatible with CBT. For information about the instances, see Using Instances.