Prerequisites Before Moving to Linux Virtual Machines in Azure
Before attempting to move certain Linux virtual machines, preparations to the virtual machine must be made for the migration to be successful.
The following table lists the name of the supported Linux distribution and the link to follow instructions for preparation:
Linux Distribution | Link for Instructions |
Ubuntu (16.04, 14.04) | |
CentOS (6.3, 7.0) | |
RHEL (6.9, 6.7, 7.4) | IMPORTANT: dracut -f -v should be replaced with dracut -force -v |
Moving Protected Virtual Machines to a Remote Site
You can move the virtual machines in a virtual protection group to Azure, where the virtual machines are replicated.
IMPORTANT: |
Due to an Azure limitation, moving over Linux VMs with static IP is not supported. |
To initiate a move:
1. In the Zerto User Interface select ACTIONS > MOVE VPG.
The Move wizard is displayed.
2. Select the VPGs to move.
At the bottom, the selection details show the amount of data and the total number of virtual machines selected.
The Direction arrow shows the direction of the process: from the protected site to the peer, recovery, site.
3. Click NEXT.
The EXECUTION PARAMETERS step is displayed.
You can change the following values to use for the recovery:
■ Commit Policy
■ Force Shutdown policy
■ Keep Source VMs - Prevents removal of the protected virtual machines at the protected site.
Note: If reverse protection is specified, the Keep Source VMs option is grayed out because the virtual disks of the VMs
are used for replication and cannot have VMs attached. If Keep Source VMs is selected before reverse protection is
specified, the Keep Source VMs selection is canceled.
4. To change the commit policy, click the field or select the VPG and click EDIT SELECTED.
a) To commit the recovery operation automatically, with no testing, select Auto-Commit and 0 minutes.
b) Select None if you do not want an automatic commit or rollback. You must manually commit or roll back.
c) To test before committing or rolling back, specify an amount of time to test the recovered machines, in minutes.
This is the amount of time that the commit or rollback operation is delayed, before the automatic commit or rollback action is performed.
During this time period, check that the new virtual machines are OK and then commit the operation or roll it back.
The maximum amount of time you can delay the commit or rollback operation is 1440 minutes, which is 24 hours.
Testing that involves I/O is done on scratch volumes.
■ The more I/Os generated, the more scratch volumes are used, until the maximum size is reached, at which point no more testing can be done.
■ The maximum size of all the scratch volumes is determined by the journal size hard limit and cannot be changed.
■ The scratch volumes reside on the storage defined for the journal.
5. To specify reverse protection, whereby the virtual machines in the VPG are failed over to the recovery site and then protected in the recovery site, back to the original site, either:
■ Click REVERSE PROTECT ALL. This activates reverse protection on all the VPGs that you plan to Failback. The system default values for this procedure will be assigned to all the VPGs.
-or-
■ Click the Reverse Protection field.
If you want to configure the VPG for reverse protection, click the REVERSE link.
The Edit Reverse VPG wizard is displayed and you can edit the reverse protection configuration. The parameters are the same as described when you create a VPG, with the following differences:
■ You cannot add or remove virtual machines from the reverse protected VPG.
■ By default, reverse protection is to the original protected disks. You can specify a different storage to be used for the reverse protection.
■ When replicating a VPG from Azure, re-IP is always enabled. If VMware Tools or Microsoft Integration Services are available for vSphere or Hyper-V respectively, for each virtual machine in the VPG, the IP address of the originally protected virtual machine is used. Thus, during failback the original IP address of the virtual machine on the site where the machine was originally protected is reused. However, if the machine does not contain the utility, DHCP is used. The host version must be 4.1 or higher for re-IP to be enabled.
When committing the Failback, you can reconfigure reverse protection, regardless of the reverse protection settings specified here. For more information see
Reverse Protection For a Moved VPG.
6. Click NEXT.
■ A warning appears informing the user that the virtual machines or vCD vApp will be removed from the other VPGs that are protecting them.
■ If your VPG has a vCD vApp, or if there are no other virtual machines left to protect, the entire VPG will be removed.
7. Click OK.
The MOVE step is displayed. The topology shows the VPGs and the virtual machines that are about to be moved from the on-premise site to Azure.
8. Click START MOVE to start the Move.
A warning message appears, presenting a summary of your Commit Policy.
9. Review the Commit Policy summary, and either click Change Settings, or click START MOVE to start the move.
10. If a commit policy was set with a timeout greater than zero, as described in step
4, you can check the new virtual machines on Azure before they are removed from the protected site.
Note: If a virtual machines exists on the recovery site with the same name as a virtual machine being migrated, the machine is moved and a number is added as a suffix to the name, starting with the number 1.
The status icon changes to orange and an alert is issued, to warn you that the procedure is waiting for either a commit or rollback.
All testing done during this period, before committing or rolling back the Move operation, is written to a copy of the recovery disks created during the Move operation.
Note: You cannot take a snapshot of a virtual machine before the Move operation is committed and the data from the journal promoted to recovery disks, since the virtual machine disks are still managed by the VRA and not directly by the virtual machine. Taking a snapshot of a machine that is in the process of being moved will corrupt that machine.
11. After checking the virtual machines on the recovery site, choose one of the following:
■ Wait for the specified Commit Policy time to elapse, and the specified operation, either Commit or Rollback, is performed automatically.
■ Click the
Commit or
Rollback icon (
) in the specific VPG tab.
■ Click Commit to confirm the commit.
■ Click Rollback to roll back the operation, removing the virtual machines that were created on the recovery site and rebooting the machines on the protected site. The Rollback dialog is displayed to confirm the rollback.
You can also commit or roll back the operation via the TASKS popup dialog in the status bar, or by selecting MONITORING > TASKS.
After the new virtual machines are up and running and committed in the recovery site, the powered off virtual machines in the protected site are removed from the protected site. Finally, data is copied from the journal to the recovery disks copies, attached to the new virtual machines in Azure.
■ 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 137. You can also change the instance size of new virtual machines when you create or edit a VPG.
Note: If the new virtual machines do not power on, the process continues and the new virtual machines must be manually powered on.
Note: By default, every Azure virtual machine is created with an additional temporary volume. This temporary volume is a local SSD disk. The size of the SSD disk depends on the instance size of the virtual machine.
Note: If you did not define a private IP for a virtual machine in the VPG definition, during recovery Azure sets the private IP from the defined subnet range.
