The Move Process

Use the Move operation to move groups of protected virtual machines from a protected site to a recovery site in a planned migration.

When you perform a planned migration of virtual machines to a recovery site, Zerto assumes that both sites are healthy and that you plan to relocate the virtual machines in an orderly fashion without loss of data.

Note: To recover virtual machines on the recovery site during disaster recovery, see Managing Failover.

A move differs from a failover in that with a move you cannot select a checkpoint to restore the virtual machine to. Also, to ensure data integrity, the protected virtual machines are powered off completely and a final checkpoint created so that there is no data loss before the move is implemented.

You can initiate the Move operation from either the protected site or recovery site.

The MOVE operation has the following basic steps:

• Shutting down the protected virtual machines gracefully. This ensures data integrity.

If the machines cannot be gracefully shut down, for example, when VMware Tools or Microsoft Integration Services is not available, you must manually shut down the machines before starting the Move operation or forcibly power off the virtual machines as part of the Move operation. If the machines cannot be gracefully shut down automatically and are not shut down manually and the Move operation does not forcibly power them off, the Move operation stops and Zerto rolls back the virtual machines to their original status.

• Inserting a clean checkpoint. This avoids potential data loss since the virtual machines are not on and the new checkpoint is created after all I/Os have been written to disk.
• Transferring all the latest changes that are still in the queue to the recovery site, including the new checkpoint.
• Creating the virtual machines in the recovery site and attaching each virtual machine to its relevant virtual disks, based on the last checkpoint.
Note: The new virtual machines are created without CD-ROM or DVD drives, even if the protected virtual machines had CD-ROM or DVD drives. Also, as long as the virtual machines are created, the operation is considered successful, even if the virtual machines are not created with their complete definition.
• Powering on the virtual machines making them available to the user. If applicable, the boot order defined in the VPG settings is used to power on the machines.

If the new virtual machine does not power on, the process continues and the new virtual machine must be powered on manually.

• By default, automatically committing the Move operation without testing. However, you can also run basic tests on the new instances to ensure their validity. Depending of the commit/rollback policy that you specified for the operation, the operation is committed, finalizing the move, or rolled back, aborting the operation.
• If Keep Source VMs is not selected, the protected virtual machines are removed from the inventory.
Note: If Keep Source VMs is not selected, and the virtual machines or vCD vApp are already protected in other VPGs, continuing with the operation will cause the virtual machines or vCD vApp to be deleted from other VPGs that are protecting them and to the journals of these VPGs to be reset. In the event of vCD vApp or if no other virtual machines are left to protect, the entire VPG will be removed.
• Promoting the data from the journal to the machines. The machines can be used during the promotion and Zerto ensures that the user sees the latest image, even if this image, in part, includes data from the journal.
Note: Virtual machines cannot be moved to another host during promotion. If the host is rebooted during promotion, make sure that the VRA on the host is running and communicating with the Zerto Virtual Manager before starting up the recovered virtual machines.
• If reverse protection is specified:

In vSphere to vSphere environments only:

• When moving the virtual machines in a VPG and you specify reverse protection, the virtual machines are moved to the recovery site and then protected using the values specified during the move.
• Data is promoted from the journal to the moved virtual machines and then synchronization with the original site is performed so that the VPG is fully protected.
• The synchronization performed uses the original protected disks and is a Bitmap Sync.

Considerations:

A Delta Sync will be triggered if any of the following conditions apply: ​

• From the time the VPG was moved until the time of synchronization, the original VM was powered on.​
• The original VM was migrated to a different host on the protected environment.
• The ZVM and VRA on either the protected or recovery sites are running Zerto versions older than 8.0.
• Update VPG failed.
Note:  

If the update VPG that is automatically triggered as part of the move with reverse protection fails, the VPG will enter a state of Needs Configuration.

In order to apply reverse protection, the user will have to manually edit the VPG settings.

After the user edits and saves the VPG, an update VPG event is triggered, followed by a delta sync.

In all environments except vSphere to vSphere:

• When moving the virtual machines in a VPG and you specify reverse protection, the virtual machines are moved to the recovery site and then protected using the values specified during the move.
• Data is promoted from the journal to the moved virtual machines and then synchronization with the original site is performed so that the VPG is fully protected.
• The synchronization performed uses the original protected disks and is either a Delta Sync or, if there is only one volume to synchronize, a Volume Delta Sync.
• A sync is required since the recovered machines can be updated while data is being promoted.
• Copying data from the S3 buckets to the new EBS disks of the new instances. During this process, the new instances cannot be used. The protected virtual machines are created as new instances in EC2. The default value for new instances in Zerto is m5.xlarge. If these instances do not meet your needs, you can change this value in the Policies tab of the Site Settings dialog, see Defining Site Policies. You can also change the instance type of new instances when you create or edit a VPG.

See also:

• Moving Protected Virtual Machines to a Remote Site