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.
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.
When you perform a planned migration of virtual machines to a recovery site, Zerto Virtual Replication 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 Live”, on page 173.
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 Virtual Replication 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 new virtual machines in the recovery site and attaching each new virtual machine to its relevant VHD disk, 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, for example setting a private IP cannot be performed.
■ Powering on the new 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 virtual machines 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.
■ The default instance size for new virtual machines is
Standard D1 v2. If Standard D1 v2 instance size does not meet your needs, you can change this value in the
Policies tab of the
Site Settings dialog. For more information, see
“Configuring Disaster Recovery Policies”, on page 142. You can also change the instance size of new virtual machines when you create or edit a VPG.
■ When you create a virtual machine in Azure you are provided with a temporary volume automatically. This temporary storage is D: on a Windows virtual machine and it is /dev/sdb1 on a Linux virtual machine.
■ Temporary volume size varies according to the instance size you have selected.
■ On Windows, the temporary volume will be using the next available drive letter.
For example: If you have two volumes connected to the protected virtual machine, Azure will use C and D, and allocate E for the temporary volume drive.
Notes:
■ If virtual machines or vCD vApp are already protected in several VPGs, and reverse protection is configured, the virtual machines or vCD vApp are deleted from the protected site. This will result in the removal of these virtual machines 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.
Protecting virtual machines in several VPGs is enabled only if both the protected site and the recovery site, as well as the VRAs installed on these sites, are of version 5.0 and higher.
■ If Keep Source VMs is selected, the protected virtual machines are not removed from the protected site.