I’ve been using Server 2012 for sometime now, but I’ve just recently setup Hyper-V on a few of those systems. I think over all Hyper-V’s offering really hasn’t changed much, but the addition of Replica certainly is a big one. I think it’s a great, low-cost solution for disaster recovery. I do not, however, think it should be considered an all-in-one solution. Using just the Server 2012 built-in solutions such as the built-in backup, used along with Hyper-V Replica it gets closer, but still not there. My opinion is VMware is still ahead of Microsoft by far. The gap is closing; especially in the SMB market, which Microsoft intends to keep, and VMware hopes to penetrate. I think it is worth knowing about and fully understanding uses for Hyper-V in place of VMware, but I will say in the small to medium deployments, I don’t think I’d use Hyper-V or Hyper-V Replica for DR.

The truth of the matter is Microsoft and VMware both offer a reliable Hypervisor. Just for the balloon driver alone, my preference will always be VMware. On the other hand, Microsoft’s answer to ballooning is more physical ram. Hyper-V does have Dynamic Memory (DM), which is new, and while it is nice it is not perfect. This plays a big part in deployments that need to scale. I also do not fully appreciate Microsoft’s built in backup. There are many things that Microsoft does well, but backups have never really been one of them. In Server 2012 that seems to still be true, and that plays a big part in designing DR. In practical use more times than not someone needs a new VM right away. If you are using Microsoft Hyper-V and do not have the extra memory available, you will have to get that memory before you can deploy a new VM. In the same scenario using VMware vSphere, you can deploy the VM and order the additional memory at your leisure, if it is even required.

Because of the differences in how Hyper-V and ESXi allocates and manages memory, I think VMware makes a far better Hypervisor for disaster recovery. Suppose your company doesn’t have a DR site, or even extra servers to be DR systems! While Microsoft certainly supports far more white box systems than VMware, you can far over commit a ESXi host, whereas a Hyper-V host not so much. Without upsetting those pro Hyper-V it all comes down to what you prefer and how you plan. I certainly wouldn’t forgo deploying or supporting Hyper-V, it’s just not my preference. In most cases your environment was inherited. As with all networks, it is comprised of systems and software the previous or lead admin selected. Ergo, you’re stuck with what you have. Those who are lucky enough to be revamping or building a network from the ground up choose wisely. If you’re using Microsoft for virtualization there is no doubt that your DR strategy would be different than it would be when using VMware.

That being said, I found a blog here, that I think covers Hyper-V Replica extremely will. His expertise on the topic far exceeds my own, which is why rather than trying to cover Hyper-V Replica I will simply link to him. I think it’s worth others taking a look regardless if you’re already using Microsoft or VMware for virtualization. Additionally on the right hand side of my blog, under the diagram section, you can find a link to the Microsoft Hyper-V Replica Companion Reference, as well as here.

Related Posts


vSphere HA error: “The number of heartbeat datastores for host is 1, which is less than required: 2”

When the master host in a vSphere HA cluster can not communicate with a slave host over the management network, the master host uses datastore heartbeating to determine whether the slave host has failed, is Read more…

Active Directory

Export Active Directory Group Membership to CSV

Using Windows PowerShell you can easily export Active Directory group membership to CSV. First, start Windows PowerShell as an administrator and import the Active Directory PowerShell module. Import-Module ActiveDirectory Next, run the below command where Read more…

Microsoft SQL Server

Detatch database failed for Server ‘SQL-SERVER’. Error 3703

While trying to dismount a database I ran into the error: Cannot detach the database ‘Database Name’ because it is currently in use. (Microsoft SQL Server, Error: 3703). This almost always happens due to an Read more…