Hyper-V Replica Requirements and Facts

For an introduction check out the article What is Hyper-V Replica and how does Replication Work. It explains what the benefits are of using it in a production environment as a disaster recovery technology.

Hyper-V Replica Requirements

To take advantage of the Hyper-V Replica, which is included as part of the Hyper-V server role, the following pre-requisites must be met:

  • A Windows Server 2012 computer with Hyper-V Role enabled/installed.
  • The hardware that supports the Hyper-V Role.
  • Sufficient storage on both the Primary and Replica servers to host the files used by virtualized workloads.
  • Network connectivity between the locations hosting the Primary and Replica servers
  • Properly configured firewall rules to permit replication between the Primary and Replica sites
  • For data to be transferred in encrypted formatted over the network, you are required to use HTTS which requires an X.509v3 certificate which supports mutual authentication.

Hyper-V Replica Facts

  • Change Tracking Module

Hyper-V Replica works on a module named “Change Tracking”. This is a function, in a programming language or a routine which is implemented to look for any write operations on the Virtual Machine files.

  • Two Components

There are at least two Hyper-V Servers involved when configuring Hyper-V Replica feature.  One server acts as Primary Server and other acts as a Replica Server as shown in the below screenshot:

  • Windows Server 2012

Hyper-V Replica requires Primary and Replica server to be running on Windows Server 2012.

  • Workgroup or Domain Models

There is no need to have Active Directory domain Services configured for Hyper-V Replica to work. Hyper-V Replica can be implemented in both Workgroup and Domain security models. For Workgroup security model, authentication must be configured using a certificate.

  • Disaster Recovery Solution

Many people confuse with Hyper-V Replica feature as to see how it is beneficial in achieving the high availability of Virtual Machines running on the Hyper-V. Hyper-V Replica is not a failover solution. It is a disaster recovery solution meaning it does not provide automatic failover capability which is provided by the Microsoft Failover Clustering.

  • Use of Storage

Hyper-V Replica is designed in such a way that it makes the scenario work irrespective of where the virtual machine VHD file(s) resides (VHD files can be hosted on Direct Attached Storage (DAS), a SAN LUN, an SMB share on a File Server, or a Cluster Shared Volume (CSV). Hyper-V Replica can be configured to transfer Virtual Machines across Hyper-V Hosts.

  • Replication Interval

Replication Interval provided by the Hyper-V Replica feature is 5 minutes and interval cannot be changed. There are several reasons for imposing this limitation but explaining those in this article is out of scope.

  • HTTP or HTTPs Replication

The HTTP or HTTPS authentications are provided by the Network Module implemented in the Hypervisor.

  • Different Networks

Hyper-V Replica can be configured for different networks also. It allows you to configure Hyper-V Replica for Replica Server running in the different network subnet.

  • PowerShell Interaction

PowerShell is just robust as Unix shell today. Microsoft offers one-liner PowerShell commands to configure Hyper-V Replica quickly without spending too much of time in GUI.

  • Firewall Exception

A firewall exception is mandatory for Hyper-V Replica. Please note default port 80 for HTTP and 443 for HTTPS are already enabled in the Windows Firewall. The firewall rules just need to be enabled.

  • Use of VSS

Hyper-V Replica uses Volume Shadow Copy Service (VSS) on servers to take a point-in time snapshots of the Virtual Machines. You can configure Snapshots to be taken when you enable Replication for a Virtual Machine.

  • By default No Virtual Machines configured to replicate

By default, Virtual Machines are not configured to replicate. You must configure Virtual Machines to be replicated on the Primary Server which are replicated over the network to Replica Server located on the destination site.

Please stay tuned for Part 3 of this article series, in which we’ll cover how to enable and configure Hyper-V Replica.

In Part IV, we’re going to learn about Hyper-V Replica Vs Hyper-V Virtual Machine Backup and why Hyper-V Replica should not be considered a replacement for Virtual Machine backup products!


Altaro Hyper-V Backup
Share this post

Not a DOJO Member yet?

Join thousands of other IT pros and receive a weekly roundup email with the latest content & updates!

7 thoughts on "Hyper-V Replica Requirements and Facts"

  • Brian Fulmer says:

    Good summary articles. I realize you don’t want to get bogged down in the details, but to prompt exploration of the new feature-set. You might want to explicitly emphasize that backups remain CRITICAL regardless of replication – broken/deleted/corrupted files replicate just fine……

    I would add an addendum that the replication target server can ALSO run only Hyper-V Server 3.0 – the free hypervisor only system that Microsoft shipped concurrently with Server 2012. I have this configuration in production.

    Because there is no requirement for similar hardware for replication to work, only sufficient storage, this new feature means even the SMALLEST small business can use advanced disaster recovery capabilities without a huge increase in hardware and licensing costs.

    I would suppose that Hyper-V 3.0 to Hyper-V 3.0 replication would work, as well, but I have not tested that configuration. Since you have to buy the Server 2012 licenses anyway, the benefits aren’t apparent to me.

    I would also note that self-generated SSL certificates work perfectly between non-domain (workgroup only) Hyper-V servers.

    Finally (I can’t remember WHERE I picked this up, or I would give attribution) – put your VM pagefiles on a separate partition/VHDX and don’t replicate them. The traffic from pagefiles is NOT WAN friendly.


    • Nirmal Sharma says:

      Thanks Brian for the feedbacks!

      I’m going to address your queries/feedbacks in the Part III of this article series!


  • Stephen Barash says:

    Really looking forward to part three. Rather than buying a high powered server that has many redundant features, I’d like to buy two cheap servers that don’t have redundant features.

    With Server 2012 installed on both, I’d like server #1 to run several virtual machines, and have them replicate to server #2. On server #2, I’d like to run several different virtual machines and have them replicate to server #1.

    If one of the servers should fail, I could light up the replicated virtual machines on the remaining server, and have all of the virtual machines up and running. Sure performance may be constrained if this occurs, but this is far better than being down.

    Is this possible??


    • Nirmal Sharma says:

      Hi Stephen, Thank you for reading the article!

      Yes, it is possible. I will cover your scenario in part III of this article series.

      Stay tuned!


  • Stephen Barash says:

    Well, it turns out after my experiment above the 2012 replication wasn’t the panacea I’d hoped it would be.

    Simply put, I’ve found that replication IO speed necessary to keep an acceptable level of server performance negates the use of a couple of cheapo servers.

    Consider how this mechanism works – each replicated VHD snapshots, then the snapshots are copied to the replicated peer host, then each peer host merges the snapshot. Rinse and repeat every 5 minutes for each guest.

    Not only does this increase the amount of VHD storage space required, but the level of disk IO goes through the roof making server performance unacceptable. End users using the services provided by these replicated guests would experience pauses or lags every few minutes. Yes, this is even after trying every hyper-v / replication performance tweak I could find – Jumbo frames, ReFs file systems, non-replicating VHD’s for swap & temp files, etc, etc.

    Try snapshotting a few VHD’s on your guest, and then merge them all concurrently while using your guest to get an idea of what the performance penalty is like.

    Of course, if you were able to dedicate one spindle to each one or two VHD’s or had a super fast RAID array, performance could be acceptable. But then there goes your cheapo servers.

    In the end having a duplicate cheapo server on standby, ready to restore a backup made by a strong backup product such as Altaro backup is a much better solution.


    • Nirmal Sharma says:

      Hi Stephen,

      >>>Not only does this increase the amount of VHD storage space required, but the level of disk IO goes through the roof making server performance unacceptable.

      Replication engine just “tracks” the changes on all VHDs. Think of the replication engine running as a TSR program. Tracking the change in TSR mode does not require much I/O. But, of course, you will see performance issues if there are a number of changes taking place at the same time for multiple VHDs. That is acceptable since the current version of Replication Engine does not implement the “multi-threading” concept.


Leave a comment or ask a question

Your email address will not be published. Required fields are marked *

Your email address will not be published.

Notify me of follow-up replies via email

Yes, I would like to receive new blog posts by email

What is the color of grass?

Please note: If you’re not already a member on the Dojo Forums you will create a new account and receive an activation email.

Webinar M365 Security Configurations