Working With Replicas in Hyper-V 3.0 (Part 2)

If you would like to read the other parts in this article series please go to:


In the previous article in this series, I talked about the many benefits to using the Hyper-V replica feature. Although the benefits of replicating virtual machines from one host server to another more or less speak for themselves, there is a lot of work that goes into getting ready for the replication process. In this article, I want to continue the discussion by talking about some things that you will need to consider prior to deploying a Hyper-V replica.

Let’s begin

The first consideration that must be taken into account is the source and destination that will be used by the replication process. Although picking out host servers sounds really simple (and it is) the servers that you pick have major implications on the way that the replication process must be configured. Hyper-V replication is very flexible and there are four main replication paths that you can use. These include:

  • Host to host
  • cluster to cluster
  • cluster to host
  • hosts to cluster

In other words, the replication process can involve standalone Hyper-V servers, Hyper-V clusters, or any combination of clusters and standalone hosts. As previously stated however, the replication path that you choose will affect the overall configuration. Even the system requirements vary depending upon the replication path.

Before I begin discussing why the replication path has a bearing on the configuration method, I want to take a moment and give you a brief overview of how the replication process works. The reason why I am doing this right now is because there are several other considerations that you need to make when planning Hyper-V replication and those considerations will probably make more sense if you have an understanding of what is going on behind the scenes.

Hyper-V replication works a lot like the Cluster Continuous Replication feature found in Exchange Server 2007. One of the Hyper-V servers (or server clusters) is treated as the source and another host server or host server cluster is treated as the destination. Replicating virtual machines from the source to the destination is based on log shipping.

The process starts by keeping track of the write operations that are made against virtual hard disk files on the source server. The server compiles a series of logs that keep track of all of these write operations. On a periodic basis (usually every five minutes) the log files are copied to the destination server and the log file contents are used to update the virtual machines that are stored on the destination host. That is how the replication process works in a nutshell. There are a few other details that you need to be aware of, but I will be covering those details when it comes time to actually configure the replication process.

So what about some other considerations that impact the planning process? Microsoft recommends that you consider the following questions:

  • Will the source and destination servers reside behind the same firewall?
  • Will the source or destination reside on a failover cluster?
  • Does replication traffic need to be encrypted?
  • Which virtual hard drive files need to be replicated?
  • How many recovery points do you need?
  • Do you need to preserve application consistency?

All of these questions have a direct impact on how the Hyper-V replica will need to be configured. For right now, let’s deal with the first four questions.

Will the source and destination servers reside behind the same firewall?

The first question that must be considered is whether or not the source and the destination reside behind the same firewall. Your firewall configuration does not dramatically change the configuration process, but you will need to open certain firewall ports if there were firewalls between the source and destination servers. Assuming that you are using the Windows firewall, Microsoft actually provides preconfigured rules that you can use for Hyper-V replication. I will discuss firewall ports in more detail when we begin the configuration process.

Will the source or destination reside on a failover cluster?

The vast majority of the configuration process for Hyper-V replicas is the same regardless of whether or not you are replicating between a cluster and a host or another cluster. However, the use of clusters does change one aspect of the configuration process. If replication will occur to or from a cluster (or both) then you will have to use a component called the Hyper-V Replica Broker. This component makes the replication process aware of the cluster’s NetBIOS name and IP address.

Does replication traffic need to be encrypted?

With Microsoft’s heavy emphasis on security it might seem strange, but virtual machine replication traffic does not get encrypted by default. If you want to encrypt replication traffic then you will have to use certificate based authentication. Microsoft recommends using certificate based authentication if you are replicating content between hosts that are geographically separated. For example, if you replicate virtual machines to a standby data center or to the cloud then you should be using certificate based authentication. On the other hand, if you are simply replicating virtual machines between two hosts that reside within the same data center then you can probably get away with using Kerberos authentication instead.

Configuring virtual machine replication based on Kerberos is a relatively simple process. However, if you plan on using Kerberos authentication then the host servers will need to belong to a common Active Directory domain or to mutually trusted domains. Otherwise you will have to use certificate based authentication.

Which virtual hard disk files need to be replicated?

The reason why this question is important is because replication occurs at the storage level, not the virtual machine level. This means that you will have to pick and choose which virtual hard disk files need to be replicated.

At first it might seem that the obvious answer to this question is that you should replicate all of the virtual hard disk files. One thing to keep in mind however, is that the replication process can be bandwidth intensive. This is especially true for virtual hard disks that incur a lot of write operations. That being the case, you might not want to replicate the virtual hard disks belonging to virtual machines that are relatively unimportant.

A more practical consideration is that there may be certain types of write operations that you don’t want to replicate. For example, there is no benefit to replicating a virtual machine’s pagefile. That being the case, you can conserve bandwidth by redirecting each virtual machine’s pagefile to a dedicated virtual hard disk and then configuring Hyper-V not to replicate that virtual hard disk.


As you can see, there is a lot of planning that goes into replicating virtual machines between Hyper-V 3.0 servers. The actual configuration process usually isn’t all that difficult, the proper planning is essential to making sure that the implementation and configuration process goes smoothly. In the next article in this series, I will begin showing you how to set up and configure Hyper-V replication.

If you would like to read the other parts in this article series please go to:

Leave a Comment

Your email address will not be published.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top