One of the best features (IMHO) of Hyper-V in Windows Server 2012 is Hyper-V Replica. This feature allows you to replicate a running virtual machine on a Hyper-V server to another Hyper-V server, where it can be ready to be fired up in case of a failure at the primary server. The replication can happen as often as 5 minutes, thus providing an almost real time disaster recovery solution. The best part of this is that it is included out of the box in the Hyper-V role of WS2012.
There is an excellent reference called Poster Companion Reference – Hyper-V Replica available for download from Microsoft here – http://www.microsoft.com/en-us/download/details.aspx?id=29189. The diagram says it all.
So, from a small business perspective, how is this useful, cost effective, and can it be implemented with the limited resource constraints of the SMB budget?
For this to work, you need at least the following items.
- Two servers running Hyper-V as hosts in non-similar domains, or in workgroups. One of these would be the main server for the business. The second could be another server in the business OR it could be a server provided by your IT service organisation, who is offering a Disaster Recovery service for your business.
- A SSL Certificate for each Hyper-V server – both the primary and the replica servers. We will not be using Kerberos authorisation, because this only works in an Active Directory environment, where both servers are part of the domain. For our purposes, we are assuming a small business where we are happy to have one, let alone two servers running Hyper-V. In this case, there will most certainly not be a domain for the hosts. A domain controller in the virtual machines will not be helpful, since the hosts will not be able to authenticate with these DCs if they are not yet started.
How do we set this up? A summary of the steps taken are as follows:
- Configure the Hyper-V primary server and replica server names.
- Purchase the SSL Certificates. Install them on each of the servers.
- Enable Replication on the replica server.
- Select a VM to replicate and configure replication.
- Begin initial replication.
- Configure replication settings.
- Test failover.
Configure the server names
We need to configure the server names so that they are fully qualified domain names. This is needed in order to obtain a proper SSL certificate. Since these servers are not in a domain, any domain suffix which is accessible would be sufficient. Normally, you would use servername.yourdomain.com or similar. In order to quickly add a suffix to the domain name, you can take the following steps.
- Open up Server Manager
Go to Local Server and click on the computer name
Put in the Primary DNS suffix and click OK several times for the changes to take place
You will need to reboot the server. After that, the server name will include the full FQDN.
Changing the DNS suffix does not affect local access to the server. It merely allows the server to see itself with a fully qualified domain name, which should match the SSL certificate that is installed in the next step.
Purchase and Install the SSL Certificates
At this stage, you can obtain a SSL certificate from your favourite vendor. I use Trustico. After generating the certificate, you need to convert this into a PFX certificate and import this into the server.
If you have a certificate in a different format, there are tools that you can use to convert them. See my blog here for more information on this – http://blog.powerbiz.net.au/useful-links/ssl-certificate-tools/
Once you have the certificate, follow the instructions here to import the certificate into the server – http://blog.powerbiz.net.au/server-2012/importing-a-pfx-certificate-into-windows-server-2012/
Enable Replication on the Replica Server
Once these initial set up steps have been completed, the servers can be configured for replication following the standard guides to setting up Hyper-V Replica. A few good resources can be found here:
- http://download.microsoft.com/download/F/6/9/F6932D74-4ADD-4366-B2BE-22CE4D94E54F/Poster Companion Reference – Hyper-V Replica.pdf
The first step is to enable replication on the Replica Server.
- Open Hyper-V Manager on the Replica Server
Click on Hyper-V Settings
Select Replication Configuration, and tick Enable this computer as a Replica server.
- Select Use certificate-based Authentication (HTTPS). You change the SSL port if you want, but you will also need to change this setting on your firewall as well
- Select the Certificate
- Allow replication from any authenticated server. You can specify the server if you want more security.
Click OK to complete the page.
Click OK to acknowledge that you need to configure the firewall.
Start the Windows Firewall with Advanced Security console
- Click on Inbound Rules
- Scroll down and select the entry Hyper-V Replica HTTPS Listener (TCP-In)
Click Enable Rule
Replication is now enabled on the Replica Server.
Enable Replication for each Virtual Machine on the Main Server
The final step is to enable replication for each virtual machine that needs to be replicated.
- Open the Hyper-V Manager
Select a virtual machine, and click Enable Replication to begin the Replication Wizard
Click Next. Type in the Replica server name (including the FQDN). If you have used a non DNS hosted FQDN, you will need to manually add in the entry into the HOSTS file.
Select the Certificate for the main server. If the DNS entries are not correct, and the replica server cannot be located by the wizard, you may get the warning listed below.
Select the drives that need to be replicated. It is possible to create a replica without replicating all the drives. Read the information panel for more information.
At this point, you can choose to select more than one recovery point, and customise the VSS schedule.
You can now select the initial replication method. The choices are self-explanatory. You can also schedule the initial replication so as not to cause bandwidth congestion.
Review the settings, then click Finish to complete the wizard. If there are no errors, replication will begin immediately unless scheduled for later.
On the Replica server, the virtual machine will be created in an Off state.
Once replication has completed, you can monitor the status of replication and perform other tasks from the Replication menu
- Repeat this for all the virtual machines
There are many factors and considerations when working with Hyper-V Replica, such as bandwidth utilisation, processor utilisation, and memory requirements. These will be investigated in another blog posting. Also, we will examine the management of the replicas and look at how to run failover testing.
45 thoughts on “How to set up Hyper-V Replica for Small Businesses”
That’s a good start Boon. For SMEs, the simplest approach would be to have the Hyper-V Replica host to be located on the same subnet/VLAN as the Hyper-V Primary host, otherwise you’ll end up with routing complexity (in terms of configuration and infrastructure) in trying to plumb through access to the Hyper-V guests without modifying network configuration.
It’s also worth noting that backing up and restoring VMs on a Hyper-V Replica is not supported, so make sure you backup/restore on the Hyper-V Primary host.
Offsite Hyper-V Replica is only going to work effectively with a BGP + anycast implementation, which is well beyond most SMEs.
I agree that the setup is least complicated when both hosts are in the same subnet for failover. It is simple and complex in the respect that Microsoft appear to have made this accessible to small business, and yet, it is fairly complex to get working if the hosts are not in a domain, which will be the case for most small businesses.
Certainly, backups are still important, because the Replica feature is more a DR feature. I will still push strongly that data backups are still an important issue.
Re: Offsite replicas. I think the strategy for small business here would be to have a working cold spare VM of their critical system that they can boot up, and perhaps join back on a VPN, or be able to pull back the VM on a USB from the datacenter when needed.
Oh, there’s definite kudos to Microsoft for making this sufficiently simple so that SMBs can leverage its functionality. It would be nice if a lot more products/components were happy with an address change without any manual intervention required (other than the failover steps).
It’s still worth pointing out that Replica is a DR/BCP feature and not a backup, but it’s worthwhile pointing out that backups need to be done at the Primary host. It does have bearing on how the backup infrastructure is organised.
Offsite replicas are a great idea, but they’re not a panacea. Firing up a replica with failover network addresses may not result in a functional system and the time spent reconfiguring the replica would be better spent recovering the primary host. It would be nice if the Hyper-V Replica included Ethernet bridge tunneling, eliminating the failover addressing requirement. But this feature would only help SMBs, as Enterprise already get this through other means.
Awesome post Boon. I’m gathering all the information regarding non-domain joined replication, and thank to you now I’m able to find the right path to follow.
One question is left for me Boon. What the certificate requirements are in order to order one with our vendor?
You can purchase some SSL certificates for use with replication, OR you could also create your own.
I’m trying to test it by using makecert utility. However I’m not having any luck.
Great post – a lot to think about.
I’d like to set this up as a trial but your scenario involves purchasing an SSL certificate. Can I do this with out purchasing a certificate?
You can get a free 30 day certificate from http://www.trustico.com. If you find it workable, you can buy their certificates. Only costs $11.95 per year.
Have a look at these posts for information on converting the certificates, and importing them into the server.
Yes I did also see that on their web site – am I correct that I’d need two certificates?
Yes, that is correct. One for the Target server, and one for the main server.
You can get free SSL certificates (Class 1) from StartSSL.
I have been playing around with Hyper-V Replica for a while now and I also tried the free StartSSL certificates but these do NOT work because they don’t support Enhanced Key Usage Client Authentication which is one of the requirement.
But I have almost a working configuration using the Microsoft makecert.exe util. There is a technet article how you should use this but it is full of errors. When I got all working without any errors I will put this all together in a blog post and share it with all.
Can I use my own cert from my CA or I MUST purchase cert to make this working
i get the following error-message when trying to activate replication for a vm:
Hyper-V failed to enable replication.
Hyper-V failed to enable replication for virtual machine ‘xxx’: The handle is in the wrong state for the requested operation (0x00002EF3). (Virtual Machine ID …)
I do not find any information about the “handle” or it’s “state” and what i can do about this.
Has anyone seen this error and knows more about it?
I have seen this several times. I don’t know why it happens, but when I retry the connection it will connect after a few tries.
in the meantime this got resolved.
The proxy-settings were not correctly setup with exceptions for local addresses, resultung in the HV-Hosts to connect to each other trough the proxy even when they were in the same local subnet.
Hopefully this helps someone as the errormessage itself is not very descriptive or helpful.
This looks like it would all work well over SSL on port 443. But what if you are using a, for example, and exchange server which needs 443 for OWA/OMA?
I have attempted on 444, but did not have much luck… but not sure if my certificate setup was right.
Have you tested it over other ports?
Unfortunately, all my previous testing, and the live sites I have now are all running via VPN or local network, so I have not had the chance to test this on another port. If you change the port, you also need to ensure that the firewall is set up accordingly as well.
I have tested Replica on port 444. It works fine. You need to create a new Firewall Incoming Rule for port 444, as the built in firewall rule only opens port 443.
I thought it might. Thanks for testing.
I am pretty sure that because my self signed certs did not cover the external FQDN it dropped the connection.
i have problem since i cant get the certificate, need help to get certificate, please note that the two host server in the same lan.
Can you provide more details? It is not very clear where your problem is.
I think the biggest problem I am having is the SSL cert. Do I use the standard steps by creating a request file using IIS7? I bought an SSL from godaddy but it does not work because I can not convert it to pfx. I do not know what the private PEM key is or where to find it. Any thoughts?
Try using these tools to covert the certificate – http://blog.powerbiz.net.au/useful-links/ssl-certificate-tools/
Looking at the Trustico website, there seem to be a wide range of different SSL certificates available. Which one is the type that would be needed for this HVR to function correctly?
The most basic RapidSSL works fine. However, you can also use a self-signed certificate, since the servers are usually internal and not exposed to the outside – http://blog.powerbiz.net.au/hyperv/how-to-create-self-signed-certificates-for-hyper-v-replication/
Awesome, thanks for the great article and for your response. It is greatly appreciated!
I wonder if you might be able to pint me to any decent write ups you might know of that talk about the hardware requirements for setting up an HVR server? I assume the hardware requirements would be different from an HV host server as there would not be any running VMs on the HVR server?? Just not sure where to find info about recommended hardware information. We are looking to provide HVR for around 15-20 servers to start with. One big thing is security – we need to make sure the replica VMs that we store are encrypted somehow. Would Bitlocker be a good option to have on an HVR server? Thanks again for any guidance you might be able to provide here.
Here is a Technet article on Hyper-V security which will answer the security questions.
The hardware question is quite subjective. It depends on what the servers will do, what resources they will need, and the numbers of connections required. There would also be budget and other considerations as well.
Thanks for the link – that is quite helpful. I will look into it further and see if I can find any general recommendations on hardware to use. Thanks again!
Excellent article, thanks very much.
I have one question regarding the link to the DR site, I haven’t been able to find a clear answer.
I would like to set this up with certificate based authentication and have no problems with that. I can have my DR server stored in a datacentre and have a public IP with what ever port forward are required. But I cannot get a VPN between the sites. Will this work with just 443 open to my DR server?
All you need is a single port open on that public IP. A proper 3rd party certificate is highly recommended in this case.
You don’t even have to use port 443. You can use a different port. This can be set up in the Replica Settings.
A VPN will make things more secure but it is not required for this to work.
Excellent, thank you for the information
Excellent guide.., many thanks..
One question, I have IIS installed on both my Hyper-V hosts but it is not used…. I put it on there when I was testing a few things…
So, now that we have SSL certs installed do I actually need IIS on the server..?
If you have SSL certs already installed on your Hosts and they are accessible to HyperV replication, then you should be able to use them.
Would it be okay to uninstall IIS…?, would this cause any problem with the SSL certs…?
You can view the certificates installed on the server using the Certificates Snap-in – http://technet.microsoft.com/en-au/library/cc754431.aspx
I just want to clarify for anyone reading this that it is best practice to have the Hyper-V machines in a domain.
Also that domain CAN (and probably should) be the SBS2011 domain. It is a myth that this wall cause any problems with Hyper V. There is no issue regarding order of start-up – the machines will start (and you can log in) quite happily with a DC offline. Of course always have a well documented local admin account.
Also, you must NOT install any roles on the Hyper V machines – especially not a DC role.
Great step by step guide.
You solve my problem 🙂
Thank you soo much