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

Two types of replications:

Protection
Protecting a vApp or a virtual machine keeps the workload running in the source site.
Migration
Migrating a vApp or a virtual machine 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 the 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.

For replications to and from sites backed by VMware Cloud Director with the Classic data engine selected, when starting a replication with a virtual machine that is already configured for replication by another replication solution, VMware Cloud Director Availability reconfigures it for replicating.

Replications Use Cases

VMware Cloud Director Availability supports cross-site replications between the following source and destination sites, as shown in the following table, depending on the source and the destination and the activated data engine:

  • Classic data engine supports both replication types - protections and migrations: Yes
  • VMC data engine supports migrations only: Future

For more information, see Activate the data engines for replicating workloads.

Table 1. VMware Cloud Director Availability cross-site support
Source site* Destination site
VMware Cloud Director site On-premises vCenter Server CDS-managed AVS SDDC CDS-managed GCVE SDDC CDS-managed OCVS SDDC CDS-managed on-premises pVDC CDS-managed VMC SDDC
VMware Cloud Director site Yes Yes Yes Yes Yes Yes Future
On-premises vCenter Server Yes Yes** Yes Yes Yes Yes Future
CDS-managed AVS SDDC Yes Yes Yes Yes Yes Yes Future
CDS-managed GCVE SDDC Yes Yes Yes Yes Yes Yes Future
CDS-managed OCVS SDDC Yes Yes Yes Yes Yes Yes Future
CDS-managed on-premises pVDC Yes Yes Yes Yes Yes Yes Future
CDS-managed VMC SDDC Future Future Future Future Future Future Future

* For architecture and for deployment information about the source and destination sites, see the following documentation:

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 the destination sites and 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, applicable for all versions.
Target RPO of Protections
RPO is the longest tolerable time period of data loss from a protected workload.
For example, a 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: Migration 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. To reduce the volume of event data, configure a longer RPO or limit the number of days that the vCenter Server instance retains event data.

Quiescing

To achieve a consistent state, 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 user 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 both to see and interact 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 the 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 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.

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.

  • Changing a replicated virtual machine name, depending on the replication source:
    • For replications from Cloud Director sites as the source, the destination virtual machine receives the new name within five minutes.
    • For replications from on-premises sites as the source, or vSphere DR and migration between two vCenter sites, keep the name of the destination virtual machine unchanged.
  • 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 during a manual synchronization in the destination site.

Replicating Thin or Thick Provisioning Virtual Disks

After starting a replication or changing its storage profile, VMware Cloud Director Availability creates the independent disk with a 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 2. 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 disk provisioning type does not change during the replication lifespan, neither when performing a failover nor when performing a migration.

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 disk provisioning type always depends on whether a replication uses a seed. For information about the seeds, see Using replication seeds.
  • When using seed in the replication, 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 disk in the destination site, regardless of the storage policy of the organization VDC.
  • When not using seed in the replication, the provisioning of the replicated disks follows the preceding logic.

Replicating Other Storage

Non-volatile memory express (NVMe)
To replicate virtual machines with an NVMe disk controller, VMware Cloud Director Availability requires that both the source and the destination sites run vCenter Server 7.0 U2 or later, and ESXi 7.0 U2 or later.
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 replicated.
  • RDM in physical compatibility mode is skipped from replication.
Multi-writer Disks
VMware Cloud Director Availability does not replicate disks in multi-writer mode.
Independent Disks
VMware Cloud Director Availability does not replicate independent disks.
Change Block Tracking (CBT)

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

IOfilters
VMware Cloud Director Availability does not support vSphere APIs for IO Filtering neither in the source site, nor in the destination site. VMware Cloud Director Availability cannot replicate a source virtual machine assigned with a VM Storage Policy that contains IOFilters. You cannot assign such a policy to the destination virtual machine either. Before replicating a virtual machine, ensure its assigned VM Storage Policy does not contain IOFilters. Do not assign VM Storage policies with IOFilters to virtual machines configured for replication.

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.