Table 2. Working files
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. While relatively small, the size of the .vzmap file is directly proportional to the size of the VMDK it is based on.
During replication, the .vzmap file is stored on the target VA.
A script created by the replication process to roll back changes on the target VM if there is a replication failure. This file created on the target VA at the start of the replication process and removed at the end.
This file is a temporary file that records original data of changed blocks since the replication started. One for each VMDK replicated. If there is a replication failure such as a network failure, the vzundo-script can be run to restore files to their original state. These files are created on the VA by the replication process and removed when the job is completed.NOTE: The .vzundo file is as large as the amount of changed data replicated during a given pass. For example, if a replication pass sends 20 GB of changed data to the target VA, the .vzundo file is 20 GB.
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 start of the replication process and removed when disk replication is completed.
Change block filter file. One for each hard disk when Changed Block Tracking (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 is later combined with the .vmdk-abbt.vztemp file into -flat-map.vztemp and removed.
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 and changed data block offsets that need to be compared to the .vzmap file at the target 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.
vRanger supports VMware® ESXi™ replication by way of the vRanger VA, which leverages the VMware® HotAdd disk transport mechanism. After the VAs are configured and deployed, the use of the VA is automatic and transparent. The following lists some key points about replicating with the VA:
• For instructions on deploying and configuring the VAs, see the Quest vRanger Installation/Upgrade Guide.
• The VM hardware cannot be changed during replication. For this reason, the VM must be at a hardware version level that is compatible with both the source and target servers. The VMware® ESXi™ version of the source and target hosts does not matter, as long as the VM hardware is supported on both ESXi versions. For more information on VM hardware versions and compatibility, see the VMware documentation at .
When replicating a VM that contains user snapshots, vRanger replicates all the snapshots in the chain from the current snapshot to the base disk. At the target side — the VM to which changes are replicated — the snapshots are merged into a single disk.
Snapshots not in the chain of the current snapshot are not replicated. In the following image, ss2 is the current snapshot. Only ss1 and ss2 are replicated. Snapshot 3 (ss3) is a lateral snapshot to ss2, while ss4 is a child to ss2.
If you make hardware changes on the source VM, you need to configure the target VM in the same way before the next replication pass. You might also need to edit the replication job to include the new hardware.
ABM filters deleted data blocks so that only active blocks are scanned and streamed to the target. White-space detection eliminates the need to compress, stream, and write zero blocks during the replication process. vRanger offers the following ABM settings options:
vRanger offers or standard . Each of these replication modes has the option of ABM. 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 difference between the replication modes is how vRanger identifies VM changes to replicate. For more information, see the following topics:
CBT tracks the disk block changes made by the source VM. When enabled on the source host, CBT records the blocks that have changed since the last replication pass and transfers them to the target host without scanning the VMDK. CBT only identifies these disk-sector changes when VMware® ESXi™ version 6.0 or later is installed on both of the hosts being used for replication.
NOTE: CBT must be enabled for each VM that you want to replicate. VMware vSphere® supports CBT, and most VMs running in this environment can use it.