I ran into this scenario when attempting to configure a demo environment.
The source environment had a single Hyper-V host, but, it was also configured as a Hyper-V cluster. Why this was is unclear, but it posed some issues when attempting to configure Azure Site Recovery (ASR) to replicate a demo Virtual Machine.
Firstly, to provide some context, the Hyper-V host was running on an HP Blade BL460C G7 with 2 x Intel Xeon E5645 CPUs (6 Cores per), and 48 GB of RAM.
It was running the Windows Server 2016 Operating System, but the Core installation (not Nano). However, although it was a single host, it was also configured as a cluster. Therefore, the storage location for VMs and their disks were targeted at Cluster Shared Volumes (CSVs).
All of that might seem fine, except for the oddity of having a standalone host as a cluster. But, it at least provides flexibility in expanding the cluster with additional hosts in the future.
The problem with this configuration occurs when attempting to use Azure Site Recovery (ASR) to replicate VMs into Azure.
I was able to install the Microsoft Azure Site Recovery Provider and associate the Hyper-V host with the Hyper-V Site I created in the Recovery Services Vault.
ASR Provider on Windows Core
A quick note on installing the Microsoft Azure Site Recovery Provider on Hyper-V (running a Core OS version).
Since the Hyper-V host was running Windows Server Core, there’s no GUI to log into to download and install the ASR Provider. So, I download the Provider and copied it into the host’s C:\ drive.
I attempted to follow the Command-line Provider and Agent installation instructions provided by Microsoft. However, instead of using Command-Line, I tried to use PowerShell, so that I could use PowerShell remoting.
After successful installation of the Azure Site Recovery Provider, the next step was to register the Provider with the target Recovery Services Vault. That is accomplished with the following command: DRConfigurator.exe /R /FriendlyName <friendly name of the server> /Credentials <path of the credentials file>
But it wouldn’t work through PowerShell remoting. So, ultimately I ended up RDPing into the Hyper-V host and running the registration through the command-line interface there.
Now with the Azure Site Recovery Provider installed and registered with the Recovery Services Vault, we can start the replication of our Virutal Machines to Azure, right?
When a Cluster Isn’t a Cluster
Remember how at the outset I explained that the single Hyper-V host was actually configured as a cluster, using Cluster Shared Volumes (CSVs)?
Well, when I attempted to replicate a single Virtual Machine to Azure, I encountered an error.
The error occurred with the Identifying the replication target job. Here is the error details:
ERROR ID: 70153
Cannot enable protection as the virtual machine is not highly available.
VM ‘GSIDemoVM01′ is part of the cluster ‘gsidhvcluster_demo_gsilabs_ca’ but is not highly available.
Hyper-V replication to Azure requires virtual machines that are part of a cluster to be highly available. Make sure that the virtual machine is made highly available and retry the operation.
Notice the error message says “Cannot enable protection as the virtual machine is not highly available.” And that the recommendation states “Hyper-V replication to Azure requires virtual machines that are part of a cluster to be highly available.”
But, in my case, the target Virtual Machine was created using Hyper-V Manager for the purpose of demonstrations to customers. And since this is operating on a single host, I didn’t really think about high availability.
In short, I thought the Virtual Machine could not be made highly available since, although technically hosted on a cluster, there is only a single-node.
My only option at this point, I thought, was to revert the Hyper-V host from a single-node cluster, back to a standalone host. But, this is not true.
Apparently, even if you have a single-node cluster, you can still make your Virtual Machines highly available. I find this rather confusing, since there’s nothing HA about a single-node cluster. But either way, here are the steps to follow:
- Start Failover Cluster Manager
- Expand the cluster Roles
- Select the Configure Role in the Actions view
- Click Next to the introduction wizard
- In the Select Role dialog box, select Virtual Machine as the type and click Next
- Select all the virtual machines you want to make highly available and click Next
After adding the target Virtual Machine into the Failover Cluster (even though it was already hosted and operating on the standalone Host/Node), Azure Site Recovery was able to successfully identify the replication target and enable its replication.
I am not a clustering or Hyper-V expert, but it’s interesting that this scenario occurred. It’s not likely to occur in a Production environment, and a Lab or Dev/Test environment may only have a single host, but not be configured as a cluster.
As an FYI, Azure Site Recovery does not support single-node clusters. It may in the future, but not at this point in time. So keep this in mind if you’re trying to use Azure Site Recovery in a scaled-down environment.