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.
- 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
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:
|
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) |
|
|
Oracle Cloud VMware Solution (OCVS) |
|
|
Migration to VMware Cloud Director service in the Migration to VMware Cloud Director service Guide.
Represents a non-operational use case.
Represents an inactive use case that might be operational in a future version.
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 |
||||||
|
VMware Cloud on AWS | Azure VMware Services | ||||||
VMware Cloud Director |
Protect | Classic | ![]() |
![]() |
![]() |
![]() |
![]() |
|
VMC | ![]() |
![]() |
![]() |
![]() |
![]() |
|||
Migrate | Classic | ![]() |
![]() |
![]() |
![]() |
![]() |
||
VMC | ![]() |
![]() |
![]() |
![]() |
![]() |
|||
VMware Cloud Director service with pVDC on: |
|
Protect | Classic | ![]() |
![]() |
![]() |
![]() |
![]() |
VMC | ![]() |
![]() |
![]() |
![]() |
![]() |
|||
Migrate | Classic | ![]() |
![]() |
![]() |
![]() |
![]() |
||
VMC | ![]() |
![]() |
![]() |
![]() |
![]() |
|||
VMware Cloud on AWS |
Protect | Classic | ![]() |
![]() |
![]() |
![]() |
![]() |
|
VMC | ![]() |
![]() |
![]() |
![]() |
![]() |
|||
Migrate | Classic | ![]() |
![]() |
![]() |
![]() |
![]() |
||
VMC | ![]() |
![]() |
![]() |
![]() |
![]() |
|||
Azure VMware Services | Protect | Classic | ![]() |
![]() |
![]() |
![]() |
![]() |
|
VMC | ![]() |
![]() |
![]() |
![]() |
![]() |
|||
Migrate | Classic | ![]() |
![]() |
![]() |
![]() |
![]() |
||
VMC | ![]() |
![]() |
![]() |
![]() |
![]() |
|||
Provider vCenter Server |
Protect | Classic | ![]() |
![]() |
![]() |
![]() |
![]() |
|
VMC | ![]() |
![]() |
![]() |
![]() |
![]() |
|||
Migrate | Classic | ![]() |
![]() |
![]() |
![]() |
![]() |
||
VMC | ![]() |
![]() |
![]() |
![]() |
![]() |
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.
- Target RPO of Protections
- RPO is the longest tolerable time period of data loss from a protected workload.
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
Owner
- 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
. 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.
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
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
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.
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:
|
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:
|
By default, VMware Cloud Director Availability 4.4 and later for new replications:
- To and from cloud sites backed by VMware Cloud Director provision the disk type, depending on whether the destination storage allows thin provisioning in the VMware Cloud Director organization VDC. For more information, see Modify the VM Provisioning Settings of an Organization Virtual Data Center in the VMware Cloud Director documentation.
- 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.
- When not using replication seed, the replica disks type follows the logic explained above.
- When using replication seed, the provisioning of each replica disk retains the provisioning of each replication seed virtual machine disk:
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.
- 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
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.