Hyper-V Failover Cluster as a Primary or Replica Server

Failover Clustering has proven its value in making virtualized workloads highly available.  We saw this in Windows Server 2008 using Quick Migration and then in Windows Server 2008 R2 with the addition of Live Migration. Failover Clustering can also play an important role as a Replica Cluster.  To accommodate this, a new role has been added in Failover Clustering called the Hyper-V Replica Broker.  A new resource type, Virtual Machine Replication Broker, was added to support this new Role.

Failover Replication Broker Architecture

The Hyper-V Replica Broker runs in a Replica cluster and provides a Replica server name (connection point (a.k.a.  Client Access Point (CAP))) for initial virtual machine placement when contacted by a Primary server. After a virtual machine is initially replicated to the Replica Cluster, the Hyper-V Replica  Broker provides the virtual machine to Replica Server (cluster node) mapping to ensure the Primary server can replicate data for the virtual machine to the correct node in the cluster in support of mobility scenarios on the Replica side (e.g. Live\Quick Migration, or Storage Migration).

The Hyper-V Replica Broker is used to configure the replication settings for all nodes in the cluster.  In standalone Hyper-V servers, the Hyper-V Manager is used to configure replication settings.  The Failover Cluster Manager is used to configure replication settings in the Replica cluster.  Using the Hyper-V Replica Role, Replication Settings across the entire cluster are set.


 The replication settings are the same as those for standalone Hyper-V servers.


 Network Considerations for Hyper-V Replica Scenarios

There are scenarios where the Replica server, or Replica cluster, will reside at a Disaster Recovery (DR) site located across a WAN link and the DR site uses a completely different network-addressing scheme than the Primary site.  In this configuration, when virtual machines are failed over to a DR site, a new IP configuration will be needed for each network configured in the virtual machine.  To accommodate this scenario, there is built-in functionality in Hyper-V Replica where virtual machines network settings can be modified to include configuration information for a different network at a DR site.  To take advantage of this, the Hyper-V Administrator must modify the network configuration for each replicated virtual machine on the Replica server.  If connectivity to networks at the replica site is required, the settings for all networks a virtual machine is connected to must be modified. The Hyper-V Administrator can provide both IPv4 and IPv6 configuration information for a virtual machine.  The Failover TCP/IP setting, which is available after replication is enabled for the virtual machine, is used to provide the network configuration information in the virtual machine.


The addressing information provided is used when a Failover action (Planned Failover or Failover) is executed.  The configuration of the Guest virtual machine IP settings in this manner only applies to Synthetic Network Adapters and not Legacy Network Adapters.  The operating system running in the Guest virtual machine must be one of the following – Windows Server “8” Beta, Windows Server 2008 R2, Windows Server 2008, Windows Server 2003 SP2 (or higher), Windows 7, Vista SP2 (or higher), and Windows XP SP2 (or higher).  The latest Windows Server “8” Beta Integration Services must be installed in the virtual machine.

The information is reflected in the virtual machine configuration file located on the Replica server.


Marcos Nogueira

With more than 18 years experience in Datacenter Architectures, Marcos Nogueira is currently working as a Principal Cloud Solution Architect. He is an expert in Private and Hybrid Cloud, with a focus on Microsoft Azure, Virtualization and System Center. He has worked in several industries, including Aerospace, Transportation, Energy, Manufacturing, Financial Services, Government, Health Care, Telecoms, IT Services, and Gas & Oil in different countries and continents. Marcos was a Canadian MVP in System Center Cloud & Datacenter Managenment and he has +14 years as Microsoft Certified, with more than 100+ certifications (MCT, MCSE, and MCITP, among others). Marcos is also certified in VMware, CompTIA and ITIL v3. He assisted Microsoft in the development of workshops and special events on Private & Hybrid Cloud, Azure, System Center, Windows Server, Hyper-V and as a speaker at several Microsoft TechEd/Ignite and communities events around the world.

4 Replies to “Hyper-V Failover Cluster as a Primary or Replica Server

  1. Hi there. Do you know if you can replicate from a HA Cluster at your primary data center to a NON clustered environment for DR? We have a 3 node HyperV cluster using iSCSI CSVs for production. I’d like to be able to replicate a subset if individual VMs to a DR site.. probably to a single server with internal storage to save on costs. Can HA/Clustered VMs be replicated to be non-HA on a non HA environment?

    1. Hi Scott,

      Yes you definitely can! You can set you replica to another Hyper-V server, it doesn’t have to be the same architecture (like Clustered or Standalone).
      It doesn’t to be even on the same domain.
      Basically you can have you DR site in where you want. The only requirement beside Hyper-V 2012 and storage space is internet connection (preference with fixed IP).

  2. Hi There.Thanks for this great info.I can only replicate in one direction. i.e from stand-alone DR server to my Cluster broker in Production.If I try replication the other way it says Kerberos authentication failed – this is really driving me crazy – any idea’s?

    1. Hi Njaneke. Thanks for the feedback.
      Did you setup the Cluster Broker on the same way (like this post)?
      Are you using certs? If yes make sure that all node of the cluster have the same cert.

      With Windows Server 2012 R2 you can replicate to more than you server. You can build a chain of server to replicate VMs.

Leave a Reply

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