By replicating the workload from the source site to the destination site, VMware Cloud Director Availability protects or migrates vApps and virtual machines. These replications are either incoming from a source site or outgoing to a destination site. One vApp or one virtual machine replicates only to one destination site.

Replicate a single workload by protecting or migrating its vApps and virtual machines from one source site, to a single destination site.

Replication Types

The replications are two 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.

The providers allow 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 provider must modify the default policy. Alternatively, to keep disaster recovery only for subscribers, the provider assigns 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 replications to and from sites backed by VMware Cloud Director with Data engine Classic selected:

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 sites:
Sites Solution Description
On-premises and cloud vCenter Server sites vCenter Server VMware Cloud Director Availability 4.4 introduces:

vSphere DR and migration between vCenter Server sites:

  • A tenant on-premises SDDC, managed by On-Premises to Cloud vCenter Replication Appliance.
  • A provider cloud site in an on-premises SDDC, managed by vCenter Replication Management Appliance.
On-premises site and cloud site backed by VMware Cloud Director vCenter Server An on-premises SDDC, managed by On-Premises to Cloud Director Replication Appliance.
VMware Cloud Director A private cloud site in an on-premises SDDC, managed by Cloud Director Replication Management Appliance.
VMware Cloud on AWS VMC vCenter Server An SDDC in VMware Cloud on AWS, managed by On-Premises to Cloud Director Replication Appliance.
VMware Cloud Director service A VMware Cloud Director instance in VMware Cloud on AWS, managed by Cloud Director Replication Management Appliance.
Azure VMware Services VMC vCenter Server An SDDC in Azure, managed by On-Premises to Cloud Director Replication Appliance.
VMware Cloud Director service A VMware Cloud Director instance in VMware Cloud on AWS, managed by Cloud Director Replication Management Appliance.
Google Cloud VMware Engine (GCVE)
  • vCenter Server
  • VMware Cloud Director service
  • An on-premises SDDC, managed by On-Premises to Cloud Director Replication Appliance.
  • VMware Cloud Director instance with pVDC on GCVE,managed by Cloud Director Replication Management Appliance.
Oracle Cloud VMware Solution (OCVS)
  • vCenter Server
  • VMware Cloud Director service
  • An on-premises SDDC, managed by On-Premises to Cloud Director Replication Appliance
  • VMware Cloud Director instance with pVDC on OCVSA, managed by Cloud Director 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 direction and type and the selected data engine:
  • No Represents a non-operational use case.
  • Future Represents an inactive use case that might be operational in a future version.
  • Yes Represents an operational use case. *Note limitations.
Source Replicate as Data Engine Destination
VMware Cloud Director VMware Cloud Director service* with pVDC on: Tenant vCenter

Server
  • GCVE
  • OCVS
  • On-premises
VMware Cloud on AWS Azure VMware Services

VMware

Cloud

Director

 Protect Classic Yes Yes No No Yes
VMC No No No No No
Migrate Classic Yes Yes No No Yes
VMC Yes Yes Yes Yes Future
VMware Cloud Director service with pVDC on:
  • GCVE
  • OCVS
  • On-premises
Protect Classic Yes Yes No No Yes
VMC No No No No No
Migrate Classic Yes Yes No No Yes
VMC Yes Yes Yes Yes Future
VMware Cloud

on

AWS		 Protect Classic Yes Yes No No Yes
VMC No No No No No
Migrate Classic Yes Yes No No Yes
VMC Yes Yes Yes Yes Future
Azure VMware Services Protect Classic Yes Yes No No Yes
VMC No No No No No
Migrate Classic Yes Yes No No Yes
VMC Yes Yes Yes Yes Future

Provider vCenter

Server

 Protect Classic No No No No Yes
VMC No No No No No
Migrate Classic No No No No Yes
VMC No No No No No
Note:

Either select the Classic data engine or the VMC data engine but not both.

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

Note: For vSphere DR and migration between vCenter Server instances not backed by VMware Cloud Director, the principal always is System. This is the SSO Admin Username that registers the appliance with the vCenter Server Lookup service. This same user owns all replications, meaning all users that see a replication have full control over it.
For replications with cloud sites backed by VMware Cloud Director, the user that starts a new replication becomes its owner, depending on the selected default replication 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.
Change Default Replication Owner
In VMware Cloud Director Availability 4.4 and later, as a system administrator, to change the default replication owner for new replications, in the left pane under Configuration, click Settings, then under Site settings next to Default Replication owner, click Edit. In the Change Default Replication Owner window, select an owner as default for new replications and click Apply.
  • System organization - assigns the system administrator as a default replication owner for new replications. Tenants do not see replications owned by the system organization.
  • Tenant organization - assigns the organization in the destination* site as a default replication owner for new replications, allowing the tenants from the destination organization seeing and interacting with the new replications.
Change Existing Replications Owner
As a system administrator, to change the owner of one or more already started replications, in the left pane choose a replication direction and click Incoming Replications or Outgoing Replications, then select the replications 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 replications owner.
  • Tenant organization - assigns the organization in the destination* site as replications owner.
* Destination organization ownership applies both for replications from cloud sites to cloud sites and from on-premises sites to cloud sites. When the destination of the replication is an on-premises site, assigns the organization in the source site as a replication owner, allowing the tenants from the source organization seeing and interacting 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.

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

Note: The hardware version of the virtual machines in the source site must not be higher than the destination site. This limitation applies both for vSphere DR and migration between vCenter Server instances and for replications with cloud sites backed by VMware Cloud Director.

For information about the hardware versions, see Virtual Machine Compatibility in the vSphere documentation.

  • 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

Note: After starting a replication or changing its storage profile, VMware Cloud Director Availability creates the independent disk with thick provision VMDK, which, on its first resize, becomes a thin provision VMDK.

As a result, from the replication start or change of storage profile until the first resize, the consumed storage equals double the source virtual machine size.

Table 1. Replication Alignment with the Destination Storage Profile
Replications Replica Disk Provisioning Type
Replications using seed Thin provision seed disk Thin provision
Thick provision lazy zeroed seed disk Thick provision lazy zeroed
Thick provision eager zeroed seed disk Thick provision eager zeroed
New replications with no seed in VMware Cloud Director Availability 4.4 and later Allowed organization VDC thin provisioning. Thin provision
Disallowed organization VDC thin provisioning. Thick provision lazy zeroed
Existing started replications:
  • in earlier VMware Cloud Director Availability versions.
  • after upgrading to VMware Cloud Director Availability 4.4.
 Retain the existing disks types, depending on the seed disk types
vSphere DR and migration between vCenter Server sites When creating each replication, select one of the following provisioning formats for the destination disk:
  • Thin provision
  • Thick provision lazy zeroed
  • Thick provision eager zeroed

By default, VMware Cloud Director Availability 4.4 and later for new replications:

  • For vSphere DR and migration between vCenter Server sites, select the destination disk provisioning format when creating each replication.

The disk provisioning type never changes after creating the replication: starting a replication permanently provisions its replicated disks as thin or thick. The disks type does not change during the replication lifespan, neither when performing a failover nor when performing migrate.

Existing replications started in an earlier VMware Cloud Director Availability version, after upgrading to version 4.4 retain their disk provisioning type, and for the organization VDC storage policy to take precedence, delete the replications then create and start them again, without using existing replication seeds.

Seed
The replicated disks provision format always depends on whether using replication seed. For information about the seeds, see Using Replication Seeds.
  • When using replication seed, the provisioning of each replica disk retains the provisioning of each replication seed virtual machine disk:
    • Thick-provisioned replication seed disks always provision thick lazy zeroed replica disks.
    • Thin-provisioned replication seed disks always provision thin replica disks.
    For example, a replication seed virtual machine that contains one thin-provisioned and one thick-provisioned disk always replicates as one thin and one thick disks in the destination site, regardless of the storage policy of the organization VDC.
  • When not using replication seed, the replica disks type follows the logic explained above.

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.

Storage Space Consumption in the Destination

Note: Replica files keep expanding until there is space on the datastore, disregarding any restrictions in VMware Cloud Director:

VMware Cloud Director Availability resizes the independent disks associated with the replicated virtual machines to represent the actual used space by the replica data. That causes VMware Cloud Director to display the actual allocation size, which might be greater than the configured allocation size limit of the organization VDC.

Some replication settings and operations require double space in the destination storage, compared with the size of the source virtual machine.

  • For both test failover and for reverse operations, the destination storage must accommodate double the space for the disk size of the source virtual machine. For information about the prerequisites for each operation, see Test Failover a Replication and Reverse a Replication. In VMware Cloud Director Availability 4.2 and later, failover tasks require destination storage space equal to the source workload size. For information about the test failover storage consumption with examples for a datastore and for VMware vSAN storage, see VMware Cloud Director Availability Storage Requirements in the Installation, Configuration, and Upgrade Guide in the Cloud Director Site.

  • When using seed, the destination storage must accommodate double the space for the disk size of the source virtual machine. For information about the space requirements when using seed, see Destination datastore space consumption.