The Move Process
The Migration process uses the MOVE wizard to move groups of protected virtual machines from Public Cloud to a recovery site in a planned migration. You can initiate the MOVE operation from either the Public Cloud site or the recovery site.
The following topic is described in this section:
Reverse Protection With One-to-Many
The MOVE process differs from a FAILOVER in the following ways:
|
•
|
You cannot select a checkpoint to restore the virtual machine to. |
|
•
|
To ensure data integrity during a MOVE, the protected virtual machines are powered off completely and a final checkpoint is created so that there is no data loss before the move is implemented. |
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. By setting a commit policy that enables checking the recovered machines before committing the migration, you can check the integrity of the recovered machines. If the machines are in the expected state and functioning correctly, you can commit to the migration.
The migration process has the following basic steps:
|
•
|
Shutting down the protected virtual machines gracefully. This ensures data integrity. |
|
•
|
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 the disk. |
|
•
|
Transferring all the latest changes that are still in the queue to the recovery site, including the new checkpoint. |
|
•
|
Creating the virtual machines at the remote site in the production network and attaching each virtual machine to its relevant virtual disks, configured to the checkpoint specified for the migration. 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 if re-IP cannot be performed. |
|
•
|
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. |
|
Note:
|
If the virtual machines do not power on, the process continues and the virtual machines must be manually powered on. The virtual machines cannot be powered on automatically in a number of situations, such as when there are not enough resources in the resource pool or the required MAC address is part of a reserved range or there is a MAC address conflict or IP conflict, for example, if a clone was previously created with the MAC or IP address. |
|
•
|
Committing the Move operation. The default is to automatically commit the migration without testing. However, you can also run basic tests on the machines to ensure their validity to the specified checkpoint. Depending on the commit/rollback policy that you specified for the operation, after testing either the operation is committed, finalizing the Move, or rolled back, aborting the operation. |
|
•
|
(Azure environments) If Reverse Protection using preseed is specified for the Move operation, the original disks become the recovery disks and are moved into the recovery container. The virtual disks previously used by the virtual machines in the protected Azure site are used for reverse protection and the VMs are removed from Azure. The VPGs are reverse protected, and a Delta Sync is performed.The data from the journal is promoted 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. |
|
•
|
If Keep Source VMs is not selected, the protected virtual machines are removed from Public Cloud. |
Note: If Keep Source VMs is not selected, and the virtual machines, or vCD vApps are also 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.
See also: