Azure Site Recovery is a very effective service that is offered by Microsoft in the purview of Disaster Recovery as a Service (DRaaS). While being able to migrate workloads from On-premises environments be it virtual or physical, if you want to move from one data center to another data center where Azure Site Recovery would act as a DR orchestrator or from your data center to the cloud and vice versa. The whole point being that you push the downtime in your businesses to near zero or zero if everything pans out very well.

In this article, we will take a look at the various scenarios that Azure supports, the various workloads it can migrate. Also, I am going to put out a series of blogs covering many things on Azure Site Recovery related to both the classic portal and the new portal so make sure to keep checking regularly.

Azure Site Recovery Supported Scenarios

Azure Site Recovery currently supports protection of workloads in the following scenarios

  1. Workloads running in Hyper-V with one or more System Center VMM can be migrated to Azure
  2. Virtual machines running in Hyper-V without VMM
  3. Physical machines that are running Windows or Linux to Azure
  4. Virtual machines running in VMWare vSphere to Azure.
  5. Virtual machines running in Hyper-V with VMM to a secondary site such as your datacenter
  6. Virtual machines running in Hyper-V without VMM to a secondary site with SAN
  7. Virtual machines in VMWare to a secondary site
  8. Physical machines to a secondary site

Now, obviously the above said is not enough information because once you say ASR supports virtual machines running in VMWare or Hyper-V and so on, it will open doors to several other questions. For starters, what versions of VMWare vSphere are supported? What applications can be migrated? What guest OS are supported? and a ton of other questions.

The following should cover a few if not all of those questions

VMWare vSphere Environment

VMWare vSphere environment is supported by Azure Site Recovery if the Hypervisor is running vSphere version 6.0, 5.5 or 5.1. However, the supported versions of vCenter are 6.0 and 5.5 (with the latest rollouts of updates). Also, all of the virtual machines running should have VMWare tools installed.

The pre-requisites that the Virtual Machines should conform to is exhaustive. Hence, if you are intending to protect virtual machine(s) then it is important that you make sure the virtual machines match those requisites. You can refer to all of the virtual machine pre-requisites here.

Hyper-V Environment

Hyper-V environment can be divided into two scenarios.

  1. Hyper-V running with one or more System Center VMM
  2. Hyper-V running without a VMM

For Hyper-V running with one or more system center VMM:

  • The VMM should be running on windows server 2012 r2 with a Hyper-V role.
  • Each of those VMM’s should have a cloud configured. Each cloud should contain one or more VMM host groups and one or more Hyper-V host groups or clusters in each of those host groups.
  • Each of the Hyper-V host must again be running Windows server 2012 r2 with the Hyper-V role and all the latest updates. The Hyper-V server must be managed by a VMM and of course contain one or more virtual machines.

For Hyper-V with no VMM:

  • The Hyper-V host should be running on windows server 2012 r2 with a Hyper-V role.
  • The Hyper-V server should have connectivity to the internet, does not matter if it is direct or if it is a proxy connection

All the other requirements can be read here.

Now, that we have looked at the let’s take a look at the virtual machine specifications that are supported by ASR

For VMWare VM’s the supported Guest Operating Systems are as follows


  • 64 bit OS with Windows Server
  • 64 bit OS with Windows Server
  • 64 bit OS with Windows Server 2008 with SP1 or above

Note that the Windows should be installed on the C:\ drive only and it should not be a dynamic disk. Also the VM can have an RDM disk. The system language should be in English only.


  • 64 bit Red Hat Enterprise Linux 6.
  • 64 bit CentOS 6.5, 6.6, 6.7
  • 64 bit Oracle Enterprise Linux 6.4, 6.5 running Red Hat compatible kernel or Unbreakable Enterprise Kernel release 3
  • 64 bit S– USE Linux Enterprise server 11 SP3

Also note that /etc/hosts files on protected machines should contain entries that map the local host name to IP addresses associated with all network adapters.

Make sure that the Secure shell service is set to start automatically on system boot and ssh connections to the machine is allowed in the firewall rules. You do not want to miss that out and later wonder what went wrong after you are done with the failover and are trying to SSH into the machine in azure.

The host name, mount points, device names, and Linux system paths and file names (eg /etc/; /usr) should be in English only.


The file system can be only:

EXT3, ETX4, XFS, ReiserFS on S– USE Linux Enterprise server 11 SP3

Multipath software-Device Mapper (multipath) and

Volume manager: (LVM2)

The disk.enable UUID = TRUE setting has to be set in the configuration parameters of the VM in VMWare.

For Hyper-V VM’s ASR supports all those which are supported by Azure. You can find all of them here.

Azure Site Recovery in the backend takes a complete snapshot of the virtual machine which gives it the capability to replicate any application that is running on a supported virtual machine. In addition Microsoft has partnered with a few product teams to make sure those app-specific testing is also a green signal.

Azure Site Recovery Supported Scenarios

ASR supported app workloads


In this article, all the scenarios that ASR supports have been listed out. In addition to that the OS specific pre-requisites that you need to make sure for ASR to support are also listed. Most importantly, a notable point is that ASR will replicate any application that is running in the afore said supported virtual machines as it is uncorrelated to the workloads that are running inside the virtual machines.