vRanger includes an integrated replication based on the proven technology of
vReplicator. There are two options for replication: standard replication using the service console; or replication via virtual appliance (required for replication to or from VMware ESXi). The replication process is the same for each method, except as noted.
A VM is made up of a set of files, which means that replicating a VM is, in essence, replicating the set of files that make up the VM, with changes to these files that reflect user specified settings for the target VM.
The set of files replicated by vReplicator is listed below:
File Extension Description
.vmx The VM config file, one per VM
.vmxf The extended VM config file, one per VM
.nvram The VM BIO file, one per VM
.vmdk The VM hard disk file, one per hard disk or snapshot
-flat.vmdk The VM hard disk data file, one per hard disk or snapshot
-delta.vmdk The VM snapshot data file, one per snapshot
-ctk.vmdk The VM hard disk change tracking file when CB is enabled on the disk
During the replication process, the configuration files will be created and modified on the target server via the VMware API.
A set of working files is also created and used during the replication process. These files and their purposes are listed below:
File Extension Description
.vzmap Records data block offset and hash of files on the target VM. A .vzmap file is created for each of the files replicated at the end of the replication. The .vzmap file is used by the next replication pass to detect any data changes since the previous pass. It stays on the target VM as long as the job is still configured to run.
Note These files are only used in Hybrid mode for VM disk -flat and -delta files.
vzundo-script A script created by the replication process to roll back changes on the target VM in case of a replication failure. This file created in the target VM folder at the beginning of the replication process and removed at the end.
.vzundo This is a temporary file that records original data of changed blocks since the replication started. One for each file replicated. In case of a replication failure such as network failure, vzundo-script can be executed to restore files to their original state. These files are created by the replication process and removed when the job is completed.
.vmdk-abbt.vztemp Active block filter file. One for each hard disk data file when ABT is enabled. It records active data block offsets for source VM disks. This file is used against the .vzmap file to figure out data blocks that need to be streamed to the target. It is created at the beginning of the replication process and removed when disk replication is completed.
When replication is executed through the virtual appliance, handling of these files will change:
• Working files that only exist during the replication process shall be written to a temporary directory of the VA, since their existence is relevant to the BET on the VA
• Working files that exists across replication processes shall be written to their original location, since these are not truly temporary files and should be reference-able even when the job is modified to not use a VA
• The .vzmutex file shall no longer be checked similar to how it is handled in ESXi backup
vRanger support three modes of replication: Change Block Tracking (CBT), differential and hybrid, all with the option of Active Block Mapping (ABM). Note that there is no option for CBT replication. If CBT is enabled on a VM, differential repliction will query for the changed blocks without a scan.
.vmdk-abfg.vztemp Change block filter file. One for each hard disk when CBT is enabled. It records changed block offsets for source VM disks. This file is only generated when CBT and ABT are both enabled. It will later be combined with the .vmdk-abbt.vztemp file into -flat-map.vztemp and removed.
-flat-map.vztemp Disk data filter file. One for each hard disk when one of two situations are true: CB is enabled, or both AB and CB are enabled. It contains active/changed data block offsets that need to be compared to the .vzmap file at the target in order to figure out data blocks that need to be streamed to the target. It is created right before file replication starts and removed when file replication is completed
.vzcid Records target VM disk CIDs at the end of the replication pass.
.vzmutex Lock file. Indicate ownership of the VM by the current Quest application.
VM replication in general starts with replicating the source VM to the target host. Changes are applied to the target VM at user designated intervals to keep the target in sync with the source. Thus the key areas of difference among the replication modes are:
• Base target VM creation
• Detection and application of changes to the base target VM
• The rest of the section describes each replication mode in more detail.
Differential/CBT Replication
The flowchart below, and the steps that follow, describe the process for differential replication.
Base target VM creation 1 Snapshot source VM 2 Capture source VM config
4 Fill disk data and retain disk hash map 5 Persist target CID map
6 Register target VM
7 Fix network configuration on target VM 8 Delete source snapshot
Subsequent replication pass 1 Verify CID in sync 2 Snapshot source VM 3 Capture source VM config
4 Update target VM based on source config 5 Compare source disk hash with vzmap on target
6 Transfer changed blocks over to the target disk and retain new target hash 7 Update CID map
8 Refresh target VM
9 Fix network configuration on target VM 10 Delete source snapshot