Back in December, Microsoft changed Azure Site Recovery (ASR) so that it no longer required System Center to be installed on-premises. This change meant that small-to-medium enterprises (SMEs) could now afford to use Azure as a virtual disaster recovery (DR) site in the cloud. I have always thought that the SME would embrace this feature of Azure more than large enterprises, and I was delighted to see Microsoft make the change. Now, it’s time for me to start writing about using Azure Site Recovery services. In this post, I will talk about the requirements of on-premises Hyper-V host and virtual machine when you want to replicate to Azure.
Hyper-V Host Requirements
The requirements of the host are pretty simple; the host must be running Windows Server 2012 R2 Hyper-V or the free Hyper-V Server 2012 R2. Those of you that are running down-level versions of Hyper-V are seeing once again that keeping your hypervisor up-to-date offers business benefits that cannot be ignored.
Azure Site Recovery uses Hyper-V Replica (HVR) to replicate the virtual machines to the cloud. Those of you that are familiar with HVR know that the SSL option for secured replication across the Internet uses x.509 certificates. You do not need to worry about creating a PKI or self-signing certificates. The provider that you will install on each Hyper-V host (requiring local administrator rights) will create and import a certificate for each of your hosts, authenticating it against the site recovery vault that is used to orchestrate replication from your on-premises site to a geo-redundant storage (GRS) in Azure.
Note that a Hyper-V cluster will not require a Hyper-V Replica Broker role to be enabled in the cluster. You just install the agent onto each host.
Virtual Machine Requirements
This is where things get a little more complicated because the replica virtual machines must fit into a specification that Azure supports. The bad news is that any of you that have either not designed for replication to Azure or that have deployed complex virtual machines, might need to do some re-engineering. The requirements for Hyper-V virtual machines are complicated and lengthy, as some of them show evidence of the fact that Azure is running the Windows Server 2012 generation of Hyper-V. And you’ll also see some of the historical restrictions of Azure IaaS virtual machines as well. I will break down the requirements into different categories.
Virtual Machine
The following restrictions apply to on-premises Hyper-V virtual machines that you will replicate to Azure. Remember that you can select which virtual machines you want to replicate.
- Virtual Machine Type: Only Generation 1 virtual machines are supported. WS2012 R2 Hyper-V added Generation 2 virtual machines, and many customers switched to that as their default type. Either those companies will have to convert those machines back to Generation 1, or they’ll have to exclude those machines from replication to Azure.
- Virtual Machine Name: The name of the machine must be between 1 and 63 characters long and is restricted to letters, numbers, and hyphens. The name must not start or end with a hyphen.
- Guest OS: Only 64-bit guest OSs are supported. They can be Windows Server 2008 R2 or later, or CentOS, openSUSE, SUSE, or Ubuntu. Note that RedHat Enterprise Linux does not have support on Azure; I get the feeling that this has more to do with RedHat than with Microsoft.
Storage
HVR replicates the virtual hard disks of virtual machines. The following requirements apply:
- Format: VHD and VHDX are supported, but don’t get carried away with the maximum supported sizes of VHDX.
- OS Disk: There can be one OS disk and it must be between 20MB and 127 GB. Note that an OS disk in an Azure virtual machine is never bigger than 127 GB.
- Data Disk Count: As you increase the specification of your Azure virtual machines, the specification supports more data disks. You can have up to 16 data disks, but this puts your Azure replica into the A4 space.
- Data Disk Size: A data disk can be between 20 MB and 1023 GB in size.
- Shared Disks: Fiber channel disks, iSCSI attached disks and shared VHDX are not supported. This basically means that you cannot replicate guest clusters.
Networking
Your virtual machines should comply with the following:
- Number of vNICs: A virtual machine should have one virtual NIC. Azure will allows the virtual machine to replicate with an error and will select one of the NICs to be used to connect to a virtual network — you can change this NIC.
- Static IP Addresses: ASR does not support static I addresses; it will report an error, but it will not fail. The replica machine will use a DHCP-assigned IP address. This is an annoyance, as most of us statically assign IP addresses in our on-premises deployments.