Managing Failover : The Failover Process
  
The Failover Process
Use the Failover operation following a disaster to recover protected virtual machines to the recovery site.
Note: You can also move virtual machines from the protected site to the recovery site in a planned migration. For details, see “Migrating a VPG to Azure”, on page 151.
When you set up a failover you always specify a checkpoint to which you want to recover the virtual machines. When you select a checkpoint – either the last auto-generated checkpoint, an earlier checkpoint, or a tagged checkpoint – Zerto Virtual Replication makes sure that the new virtual machines on Azure are recovered to this specified point-in-time. By setting a commit policy that enables checking the recovered machines before committing the failover, you can check the integrity of the recovered machines. If the machines are OK, you can commit the failover. Otherwise, you can roll back the operation and then repeat the procedure using a different checkpoint.
The Failover operation has the following basic steps:
If the protected site or Zerto Virtual Manager is down, the process continues with the next step.
If the protected site or Zerto Virtual Manager is still running, the failover requirements are determined:
If the default is requested, doing nothing to the protected virtual machines, the Failover operation continues with the next step.
If shutting down the protected virtual machines is requested and the protected virtual machines do not have a utility such as VMware Tools or Microsoft Integration Services available, the Failover operation fails.
If forcibly shutting down the protected virtual machines is requested, the protected virtual machines are shut down and the Failover operation continues with the next step.
Creating the new virtual machines on Azure in the production network and attaching each virtual machine to its relevant VHD disk, configured to the checkpoint specified for the recovery. 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.
The protected virtual machines are created as new instances in a storage account. The default value for new virtual machines in Zerto Virtual Replication is Standard D1 v2. If Standard D1 v2 instances do not meet your needs, you can change this value in the Policies tab of the Site Settings dialog, see “Configuring Disaster Recovery Policies”, on page 137. You can also change the instance size of new virtual machines when you create or edit a VPG.
Note: The original protected virtual machines are not touched since the assumption is that the original protected site is down.
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 virtual machines do not power on, the process continues and the virtual machines must be manually powered on.
The default is to automatically commit the Failover operation 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 failover, or rolled back, aborting the operation.
If the protected site is still available, for example, after a partial disaster, the original protected site virtual machines are not powered off and are not removed.
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.
If the D:/ drive is occupied by the temporary Azure disk, recovered virtual machines in Azure require re-mapping the volumes drive letters. See https://docs.microsoft.com/en-us/azure/virtual-machines/virtual-machines-windows-classic-change-drive-letter