Hyper-V replication provides an easy and economical way to create up-to-date copies of VMs in a disaster recovery site. Being that replication is a disaster recovery feature, administrators commonly have questions about Hyper-V's suitability to replicate VMs over a low-bandwidth link (such as a wide area network link between data centers).
Generally speaking, Hyper-V replication works across low-bandwidth links, but there are some factors to consider.
The initial seeding process
One of the first factors to consider is the initial replication process, which is sometimes referred to as the initial seeding process. In this process, Hyper-V copies the virtual hard disks to the replica server.
In a low-bandwidth environment, you should avoid performing the initial seeding process across the network. For one thing, the process can take a long time to complete, and unless you have enabled the quality of service, or QoS, networking feature or a similar mechanism, this process can rob other processes of bandwidth.
Another reason you should avoid seeding a VM across a slow link is that in some cases, the rate of change could be too great. It's possible to make so many changes to the VM during the seeding process that the bandwidth limitations make it nearly impossible to synchronize all the changes once the process completes.
Hyper-V sometimes has trouble with network-based seeding of large VMs -- even in high-bandwidth environments. It is somewhat common for the seeding process to fail and have to be restarted when multi-terabyte virtual hard disks are being replicated, even when plenty of bandwidth is available.
Because of these factors, it is best to use another method to perform the initial VM seeding. Microsoft allows you to complete the seeding process either by exporting a copy of the VM to removable media or by using a copy of the VM that already exists on the replica server (for instance, you might restore a backup of a VM to the replica server).
Some administrators have found using an existing copy of a VM on the replica server as the initial copy to be a problematic option. In some cases, synchronization failures have occurred when this method is used. Therefore, it is generally a good idea to seed your VMs by exporting a copy of the VM to removable media, then importing the VM into the replica server.
The data change rate
Another factor to take into account with regard to replicating a VM across a low-bandwidth connection is the VM's rate of change. Suppose, for example, that you decided to replicate a VM every five minutes and there was an average of 100 MB worth of changes occurring every five min. If your wide area network (WAN) link is fast enough to replicate 100 MB worth of changes every five min, you theoretically have nothing to worry about. Even so, you must still consider bandwidth contention. You obviously don't want to consume all your available bandwidth with replication traffic.
Even if you have a dedicated WAN link that is used solely for replication traffic, it is still important that you not saturate the connection. Imagine a case in which there is a brief service interruption and that Hyper-V misses a replication cycle. When the next replication cycle occurs, Hyper-V will have to replicate roughly twice as much data as it usually does. You don't necessarily need enough bandwidth available to allow all of that extra data to be copied during a single replication cycle, but you do need to have enough bandwidth available to allow Hyper-V to catch up within a reasonable time.
How much bandwidth do you need?
Unfortunately, there is no single, universally accepted answer. Every VM is different. The best way to determine a process' bandwidth requirements is to temporarily set up replication to a lab server, then measure the amount of data sent during each replication cycle. You will probably need to monitor the replication process for at least a week to get an accurate feel for the process' bandwidth requirements.
Hyper-V replication will work across low-bandwidth connections as long as the available bandwidth is sufficient to keep pace with the VM's rate of change. However, it is important to keep in mind that Hyper-V's replication feature doesn't scale well. It simply isn't practical to monitor bandwidth requirements for large numbers of VMs. That being the case, larger organizations generally prefer to perform storage area network replication rather than VM replication.