Hello again, welcome back to the second of my indeterminate number of articles covering my various observations regarding differences around vSphere and Hyper-V. This post is covering host replication without a central controller. So hopefully you benefit from and enjoy this one.

As near as I can tell there is no direct analog in vSphere to compare this to.  As such I’m going to give as much of an explanation as I realistically can and show where I think this would be extremely beneficial.

Hyper-V replication does not require SCVMM or any kind of centrally managed vCenter equivalent, all it requires is two or more Hyper-V hosts that meet the necessary requirements for performing the replication. (CPU, Memory, Storage, etc….) Once that is met it is quite straight forward to do as a test.

Once you have your two Hyper-V hosts configured and have them both accessible in Hyper-V Manager you are ready to go.  On the hosts, you need to enable Hyper-V replication firewall rules (this is a security blog, your firewall is on, correct?). This is easiest if you already have a domain to join both servers to. The method I am using requires Kerberos authentication. Let’s walk through all the steps.

Launch the Hyper-V Manager application, you can do this from your local workstation if you are domain joined or RDP into any Server 2012 R2 server and launch it from there. You will get a list of servers like below, from there you simply choose the source and destination servers.

On the first server go to Hyper-V Settings. This is located on the right hand side from where the VMs are listed. Simply click on it.

Then select replication configuration:

Under that heading your first step is to enable replication:

After this you have two options, Kerberos or Certificate based authentication. Since I am doing this at home in a test domain, I am using the unencrypted Kerberos. I would recommend using certificate-based Authentication in production.

Once you’ve done that you need to authorize and setup the replica information. You then need to provide a location to store the replica files. I prefer setting a specific location that is shared out IE:(\\hostname\hypvershare$). You can leave it at the default of C:\Virtual Machines\Virtual Hard Disks if you prefer though, it’s mostly a matter of taste.

If you have multiple Hyper-V servers you may need to be more specific as the second box above allows for. This is effective in limiting what servers can replicate to each other, you really don’t want to allow limitless replication in production, but for a lab environment this should be fine.  Once you’ve configured the first server, repeat these steps on the second server.

Now we can set up replication.  Choose the guest you want to replicate. I chose my DCs and SQL box as they’re the ones that really do tend to be the most critical.  Right click one of them and select Enable Replication.

It will ask you to choose where you want the replica to go, select your other Hyper-V host and click next.

Next will come the security confirmation bits. As I chose Kerberos for testing this all looks correct. I also selected to compress the data. How much this may benefit you will vary, but it’s worth trying out to potentially save some time on the replication.

After that it asks you to choose which VHDs you want to replicate. I selected all of mine.

After you click next for the drives it will ask you for your replication frequency. These are pretty aggressive in my mind and probably would be problematic on high latency WAN links. For local recovery, they should work quite well.  Pick your preferred time and then click next.

The next option will allow you to choose the number of recovery points you want. In a home lab environment I only want the most recent, but there are arguments to be made for having more.

The last and final page has the most interesting bits, you can choose to perform the initial replicate over sneakernet. This can go a long way to negating a WAN link problem.  Additionally it will give you the size of your initial replica and allow you to schedule when the replication will first run. This is particularly handy to avoid doing the primary data transfer during business hours or at times of high bandwidth usage. (Backups, offsite disk, World Cup watching, etc…)

You will see the summary of what you chose and at this point you are done setting the replication up.  Click Finish and verify the operation completed.

If, like me, your two hosts do not have the same networking gear, you may get a popup advising you of this.

Go into settings and pick the proper network virtual switch for the new host.

This should be the last step you need to perform. If you click on the guest now under checkpoints it should show an initial replication.

View the VMs in the replica destination host and you should see the VM’s in an Off state. This is normal and should only change if the original goes down for any reason.

At this point the only remaining step for you to perform is wait for the replication to finish and then test if it works.