Replicating Hyper-V Virtual Machines to Microsoft Azure

In my previous article about enabling Microsoft Azure Site Recovery (ASR), I showed you how to configure Azure and Hyper-V hosts and clusters to enable replication of running virtual machines to the cloud using ASR services. In this post, I’ll show you the step-by-step process of replicating virtual machines to Azure, including additional configuration steps that you should perform.

Azure Site Recovery So Far…

If you’ve kept along with my previous article, then you should have already performed the following:

  1. Created a virtual network and storage account
  2. Created an ASR vault
  3. Created a Hyper-V site
  4. Downloaded and installed the ASR provider on every Hyper-V host or node in a Hyper-V cluster
  5. Associated the host(s) with your ASR vault and Hyper-V site in Azure
  6. Created a protection group that associated the Hyper-V site, and therefore the host(s), with a replication policy, and an Azure storage account

The next step is to start replicating your on-premises Hyper-V virtual machines into Azure.

Configure Virtual Machine Replication

Unlike with pure Hyper-V Replica, you will not be enabling virtual machine replication from the source host. Instead, you’ll log into the Azure management portal and navigate to Recovery Services, where you’ll enter your ASR vault and protection group. You’ll see an option to Add Virtual Machines, where clicking this option opens the Enable Virtual Machine Protection dialog. Select one virtual machine and select the operating system type, where the latter obviously affects your billing when the virtual machine is powered up. You should also select the virtual hard disk that contains the operating system.

Enabling Hyper-V virtual machine replication in Azure Site Recovery. (Image Credit: Aidan Finn)
Enabling Hyper-V virtual machine replication in Azure Site Recovery. (Image Credit: Aidan Finn)

Within this dialog, it is important to note that you can only enable protection for one virtual machine at a time . If you have multiple virtual machines, then you’ll need to revisit the dialog or use PowerShell.
Once you click the check button to signify completion of the task, Azure will communicate with the on-premises Hyper-V host that’s running the selected virtual machine via the installed provider. Your virtual machine will show an Enabling Protection status in the Azure provider while this is occurring.
Also note that you can create more than one protection group for a Hyper-V site. This lets you have some virtual machines replicate according to one policy and others that replicate with another policy. Keep in mind that a virtual machine can only be replicated once, so it may only be enabled in one of those protection groups.

Tracking Job Progress

When Hyper-V Replica (HVR) is enabled, the virtual machine must be copied to the destination site. Regular asynchronous replication will continue after this initial copy. The initial copy takes some time. How long? Well that depends on a few factors:

  • How much storage space does the virtual machine consume?
  • How much bandwidth is available between the host and Azure?
  • Have somebody configured any throttling or QoS?

In other words, I do not know how long a copy will take. Only you can determine the time it takes by doing some math.
Speaking of bandwidth, I cheat a bit when I do a demonstration. No one wants to sit around while 12 GB of data is replicated from my lab via a modest consumer-grade ADSL line with a 256 Kbps upload speed! So I create a number of virtual machines with blank dynamic VHDX files. Each file is 4 MB in size and an initial copy is done in seconds. I cannot fail these machines over, but they allow me to demonstrate the mechanics of enabling replication and recovery.
Unfortunately, at this time there is not an out-of-band method for conducting the initial copy. But I would not be surprised to see it added in the future, as this has been perviously done for Azure storage accounts and for seeding online backup.
You can monitor the progress of a copy. The first place to look is the Jobs view in your ASR vault. Everything that ASR does is a job. Each job has steps, and Azure tracks the progress of these steps.

Monitoring an Azure Site Recovery job. (Image Credit: Aidan Finn)
Monitoring an Azure Site Recovery job. (Image Credit: Aidan Finn)

The second place you can look is on the host itself in Hyper-V Manager. The status of the virtual machine will show the percentage progress of the initial copy. The Replication information tab at the bottom of Hyper-V Manager shows a quick replication summary. You can also right-click the virtual machine and select Replication > View Replication Health to see more information.
Once completed, the virtual machine will show a status of Protected in the vault’s protection group.

Configure Target Properties

When your virtual machine reaches a protected status, then HVR starts to conduct asynchronous replication according to the policy assigned in your protection group’s replication policy. The virtual machine doesn’t exist in Azure yet, as it’s only consuming storage. The virtual machine will eventually exist because of a test, or a planned or unplanned failover. At this point, we’ll have an issue if we start a replica virtual machine:

  • Size: We don’t know what specification the virtual machine will be in Azure. Azure can only run virtual machines with a pre-set number of virtual processors and memory from the Basic A-series and Standard A- and D-series.
  • Virtual Network: We must configure a virtual network to connect the virtual machine to for the eventuality that we might need to conduct a real planned or unplanned failover.

You can configure these two settings by navigating into a virtual machine via the protection group in the Azure management portal. Here you can configure the specification that the replica virtual machine will have should it ever be started up via any kind of failover. Make sure that you assign enough resources for your service requirements. I would probably go with the Basic tier when possible. The only benefits that the Standard tier provides is additional specifications, that is unless you automate the installation of Standard tier features, such as load balancing or auto-scale.
You can also set your virtual machine’s network. Remember that the virtual machine will have a single virtual network connection with a dynamically assigned address for the subnet. But you can override that with a static address after the virtual machine is deployed.

Setting the virtual machine specification and network connection in Azure Site Recovery. (Image Credit: Aidan Finn)
Setting the virtual machine specification and network connection in Azure Site Recovery. (Image Credit: Aidan Finn)

Once you are finished with your first virtual machine, you can test a failover, enable replication for the rest of the virtual machines, and configure target settings.

A Replication and Failover Strategy

The end goal of ASR is to create one or more one-click failover processes that can quickly start with little IT knowledge beyond being able to log into Azure. ASR offers recovery plans, a set of ordered steps for failing over virtual machines, requesting manual steps and running Azure Automation runbooks. A recovery plan can automate the failover of up to 50 virtual machines. There are two ways you can use recovery plans:

  • SMEs: Start up all virtual machines in the required order
  • Large enterprise: For those organizations with hundreds or thousands of virtual machines, they can create a recovery plan for each n-tier application.

Keep your recovery plan design in mind when enabling replication of your virtual machines. For example, consider whether you want to get the essentials of each service into Azure as quickly as possible, or perhaps you want to prioritize the movement of complete services with all of their HA and scalability.