To start, let me say that Hyper-V 2012 is a strong product-- a very strong product. It's entrance to the market was loud and impressive, but the noise around it has since quieted down. After spending quite a bit of time using it, and coming from the background of years on the VMware vSphere platform, I'm able to make an accurate comparison between the two and share my thoughts on how it stacks up.

<strong>Installation </strong>

For those who aren't aware, Hyper-V 2012 can be installed as a Server Role on top of Server 2012, and the installation process is just about as easy as it gets. You check the box for the Hyper-V role in the add new role wizard, and in a few minutes, it's installed and live on your server. There is also a standalone, Core-only (command line only) version called Hyper-V 2012 Server, that you can install onto the server hardware directly. The difference here is that the Role added on Server 2012 includes licensing for Server OS virtual machines that will run on top of the host, whereas the Hyper-V 2012 Server installation does not. In addition, Hyper-V Server is command line only, as it runs the “core” installation of Windows Server.

I won't spend much time on the licensing details other than to say unless you are running a small number of virtual machines, going the Datacenter edition is probably going to be the best bang for the buck, as it covers an unlimited amount of Windows Server OS VMs that run on the licensed host. To state it another way, once you pay for the Datacenter Edition license, install it on a server, and enable the Hyper-V role, all other server VMs that you subsequently run on that physical server, require no additional Server OS license.

It's important to note that at this point, you have the equivalent of a standalone hypervisor server-- a “standlone ESXi host” is a good point of comparison. You do not have the benefits of high availability, live migrations for either the virtual workload or its underlying storage, and no dynamic workload balancing.

<strong>Hardware Considerations</strong>

Throughout our time installing, upgrading, and managing Hyper-V hosts, we've found that Microsoft is very picky about the underlying hardware used, and reference their hardware compatibility list in several places (especially in the Failover Clustering Management interface, which we'll get to in a minute). While an HCL exists from the other hypervisor vendors, it's almost a background consideration in a lot of cases, as compared to Microsoft's position of putting the HCL “front and center”.

Given this fact, we'd strongly suggest to anyone deploying Hyper-V 2012, and especially those who are upgrading from previous versions, that you very carefully validate your hardware is certified for Server 2012 before going into production.

<strong>Networking</strong>
One of the major improvements in Server 2012, which has a upward and positive impact to Hyper-V, is the addition of NIC Teaming through the Server 2012 OS itself, as opposed to only being available through the use of  vendor specific teaming utilities.

The result here is a very similar capability to what I've been accustomed to having from VMware. The NIC Teaming provides the ability to load balance NICs from different vendors, NICs that are on the motherboard with NICs that are add-ons through a PCIe slot, as well as load balancing the NICs (in an “active/active” manner) without any configuration on the upstream switches.

Additionally, you can load balance your NICs in an active/standby configuration, or the commonplace active/active with "switch awareness" (a port channel in the Cisco world-- which can be “static”-- channel-group mode on in Cisco terms, or using LACP, channel-group mode active in Cisco terms).

Assuming a standard 6 or 8 NIC server design, the only real “difference” in the networking configuration for a Hyper-V server as opposed to an ESXi host is that there is generally a NIC dedicated for “outside of Hyper-V” server communication. This can be done with a team, and is something that should be discussed as part of your design and hardware purchase (to ensure you have the correct amount of NIC ports).

<strong>Hyper-V Virtual Switches</strong>
This topic took me a little while to understand how it actually applied, especially since I was trying to relate it to what I was used to working with from VMware.

&lt;DIAGRAM HERE&gt;

Imagine that you have 2 NICs in an active/active, switch independent team, that you'd like to use for the “normal” virtual machine network/LAN traffic. First, you must create this team using the NIC Teaming interface through the Server Manager in Server 2012 (this is done OUTSIDE of Hyper-V, as it's an OS feature, and not a Hyper-V specific feature).

<a href="http://egroup.jasonmangone.com/wp-content/uploads/2013/03/nicteam.png"><img class="aligncenter size-medium wp-image-7942" alt="nicteam" src="http://egroup.jasonmangone.com/wp-content/uploads/2013/03/nicteam-300x176.png" width="300" height="176" /></a>

Once configured, note the non-editable name that Windows assigns to the logical team interface, as this is what you will be creating your virtual switch to use as its communication link. This is a minor annoyance. Being able to change the name to something more usable, or having Hyper-V use the team name as opposed to t

Staying off of the Hyper-V configuration and speaking specifically to the Server 2012 OS use of the network team interface, you have the ability to specify a VLAN, and can also create additional sub-interfaces off of the team for specific VLANs. If you set no VLAN, the interface will listen for traffic on all VLANs that the upstream, physical switch is passing down to it.

If you specify one on the team interface itself, that's the only VLAN it will be listening for traffic on.

If you create a sub-interface and assign it a VLAN ID, that interface will only listen for that specific VLAN's traffic, but the logical TEAM interface will continue to listen on all others.

The recommendation for Hyper-V is to NOT create sub-interfaces on the network team interface, and to NOT assign any VLANs to the team interface, but leave the VLAN tagging to the vNICs for the virtual machines (this is a bit different than ESXi's vSwitching, which we'll outline further below).

Now, back to Hyper-V. From the Hyper-V manager utility, you'll find the Hyper-V Virtual Switch Manager in the top right corner, and once you open it, you'll have the ability to add a new network. There are three network types, but the most common and the one you'll want to create to allow virtual machines to talk to your physical LAN is the “External Network” type.

If you create a network called “Server Network”, you'll notice that you can ONLY assign it a VLAN if you share it with the management OS. What this means is that if you want to tag it with a VLAN at this level, you won't be keeping it as a dedicated network for Hyper-V, but rather will be sharing it with the Server 2012 OS you installed Hyper-V onto as well. We suggest you DO NOT check this option, and that you do not assign it a VLAN.

As part of the creation of the new network, you'll have the ability to select the network interface you want to use for it as well via a drop down menu. Once you select an interface for a new virtual switch, it cannot be used again for another one. This is important to take note of for your configuration. (NEED TO VERIYF).

So at this point, consider the diagram below, taken as a screenshot from ESXi. You have created a virtual switch, and assigned it physical interfaces on which to connect-- the center piece, and the pieces to the right.

What you have NO done, which is what confused us for a while, is create the “VM Port Groups” on the left hand side. In a typical VMware deployment, you would create a VM Port Group for each VLAN you wanted to have available to your virtual machines, and in that port group, you would set a VLAN ID. The upstream communication would be on trunking (or tagging) interfaces, and thus providing you with access to the VLANs you need-- and this part is the same in Hyper-V. What's different, however, is that Hyper-V 2012 does not have the concept of a VM Port Group. Instead, you assign a VLAN ID and “virtual port” on the vNIC of the virtual machines themselves.

So let's say that Server Network has access to VLANs 10-20, and you want to be on the “DMZ” VLAN, which we'll say is VLAN 15 in our example. On the VM you are putting in the DMZ, you would go to Edit Settings, find its NIC, and check the box to “Enable VLAN Tagging”, and specific VLAN 15. Then you'd press OK, and the VM would be able to communicate out on the network.

I know this can be a bit confusing, so if you have any questions, please do not hesitate to post in the comments or drop us an email-- we're happy to help clarify!

Failover Clustering
In order to get all of the benefits of High Availability and similar features that require the use of shared storage between your Hyper-V hosts in a “cluster”, you must installed the Failover Clustering role on your Hyper-V hosts. This is, as the name indicates, what allows you the ability to “cluster” the hosts together.

Installing this role is just as easy as installing the Hyper-V role-- simply check the box under the Features in the add new roles/features wizard, and it'll run through the install. It's worth noting that the server you are installing this role on MUST be a member of the domain at the time of installation, or it won't go through with the install.

Once the feature is installed and the server is rebooted, you must run through the Pre-Clsuter Validation report, which will check out the hardware, drivers, etc. and alert you to anything that would prevent your cluster from working and/or being supported by Microsoft.

From here, you create a new cluster, give it a name, an IP address, etc. and add your single node into it. Rinse and repeat to add additional hosts.

Any network interfaces that have an IP address assigned to them (as is usually the case for interfaces or NIC teams that are used for management, cluster heartbeats, or iSCSI storage access) will show up as Networks in the Failover Clustering management interface. You can rename them to be more readable, and as long as the subnets stay the same across hosts, all hosts can share those networks without having to do anything special to keep the names consistent.

Jumping ahead to the future state of a common Hyper-V 2012 deployment WITHOUT System Center Virtual Machine Manager (SCVMM, which we'll mention in more detail later), the Failover Clustering management utility is where you will be able to migrate your virtual machines across nodes in your cluster.

Clustered Shared Volumes
To briefly define a “Clustered Shared Volume” to someone familiar with ESXi, consider it the equivalent of a VMFS datastore. It's essentially a unit of storage that is able to be accessed by multiple hosts at the same time, just like the VMware File System (VMFS) allows. It's similar to a clustered file system given the nature of its functionality, but it still runs Microsoft's well known NTFS as the underlying file system.

In order to add a CSV to a cluster, you present the storage as appropriate for your configuration and vendor's best practices, and it becomes available to the “Add Disk” wizard, as available and cluster-capable storage. Once it has been added, you can then right click it and select “Add to Clustered Shared Volume”.

NEED MORE INFO ON THE CLUSTER/STORAGE CONFIUGRATION, ESPECIALLY ON THE PROCESS TO ADD TO AN EXISTING CLUSTER AS WELL AS WHAT ALLOWS IT TO MOUNT UNDER C: OR OTHER PATHS

Storage
One of the advantages VMware/ESXi still has over Hyper-V is its built-in, native multipathing capability. For those unfamiliar, NMP allows the use, failover, failback, and in some cases, load balancing/load distribution of all the paths to your shared storage array.

The only equivalent utility natively available in Hyper-V 2012 is the MPIO driver, which combines its use with the built-in iSCSI initiator.

For those who are familiar with and have used the NMP beyond “install and let it run”, you know how incredibly valuable and efficient it is in nearly all deployment use cases (aside from NFS, which is a different beast entirely).

It's worth noting that leading storage vendors like EMC provide their own multipathing plugins or software that you can use to provide highly enhanced, optimized path management, load balancing, and failover, In EMC's case, this software is their PowerPath V/E, or Virtual Edition, and it makes a great add-on to any Hyper-V 2012 + EMC Storage deployment.

Performance
Without having any kind of head-to-head comparison or test to benchmark the two, the performance on our Hyper-V host seemed to be very good, and on par with what we're accustomed to seeing with ESXi. One area that we saw discussed a lot on the forums, and mentioned a few times by customers, was the increased overhead of having the hypervisor install in a “not-really-baremetal” model, as is the case in Hyper-V 2012. If you installed 2012 in the full GUI mode, it'll use more memory than in the Core deployment, and if you're trying to squeeze out every bit of memory from your hardware possible, we'd suggest going the Core route.

That aside, Microsoft has referenced several times that the performance of certain software deployments, namely RDS and Citirx XenApp, is greater on Hyper-V 2012 than the other hypervisors. We are not able to verify the results, but would understand if it was true, as it'd be a safe assumption Microosft would best know how to enhance performance of a Microsoft product (RDS, which XA also uses).
Feature Parity (Need lots of research here)
If you were to believe the marketing folks, Hyper-V and vSphere 5.1 would have feature parity-- that is to say, every feature available in vSphere 5.1 is also available in Hyper-V 2012. In our experience, this is not the case, though it is pretty darn close.

One of the “features” that our customers find very valuable and use frequently, is the ability to “hot-grow” a virtual disk (VHD/VHDX in Hyper-Vs case, a VMDK in Vmware/ESXi's), and then extend it in the guest operating system. This is something that you still cannot do in Hyper-V 2012. In order to grow a virtual disk, you must shut the VM down (incurring downtime), set the size desired, and then boot it back up. In ESXi, you simply edit the VM while it's running, and the storage is immediately available to the guest.

This was one that had us scratching our heads, as one would think if VMware could do this, Microsoft certainly could, at least for their own operating systems.

While it's not something that would stop us from deploying or recommending Hyper-V to customers that fit its use case, it's definitely something that we hope to see in the very near term, as it's as close to a “must-have” feature as a non-must-have feature can get.

Management
For those looking at Hyper-V 2012 but not the System Center 2012 suite, you will find that you must use multiple management interfaces to be able to manage your virtual workloads. This includes using Hyper-V manager to directly manage the VMs, access their consoles, edit their settings, etc. as well as using the Failover Clustering interface to manage the Clustered Shared Volumes, migrate virtual machines from node to node, and perform certain maintenance tasks.

In this model, Hyper-V is less expensive, nearly equal in feature set, but a little bit of a pain to manage. Now if you purchase System Center 2012 (which in the 2012 version no longer comes as one off products, but rather the entire suite), you gain access to the Virtual Machine Manager, which is much closer in comparison to VMware's vCenter server.

Some customers choose to spring for System Center, as the other products in the suite have tremendous value above and beyond the benefits of simplified virtual workload management via VMM, and this provides a huge bang of the buck. Others have deployed Hyper-V 2012 as a way to reduce their overall costs, and decide to stick with the multiple management interfaces. Either way works, though we'd strongly suggest evaluating System Center before eliminating it from consideration (and again, not just for VMM).

Conclusion
Hyper-V 2012 makes strong competition in the current hypervisor market. Its price point allows it to win while competing on price, and its growing feature set and capabilities allow it to put up a heck of a fight in its usefulness and utility for customers-- proving its value to all areas of an organization, from the CFO/CTO, to the system admins responsible for keeping the systems online.

The Datacenter Edition of Server 2012 includes the ability to host as many Windows Server VMs as the hardware can handle for no additional cost, meaning you only buy one license for your host (assuming 2 physical processors), and no longer need to pay for a server license each time you spin up a new VM.

Combine that with the ability to Live Migrate, Storage Live Migrate, Live Migrate without shared storage (known as “Shared Nothing Live Migration”), Replication/DR capabilities via the Hyper-V Replicas, and automation through the use of PowerShell and System Center, and you've got something that should be here to stay and compete for a long time.

Customers will benefit from Microsoft stepping it up and proving to be stiff competition for VMware as is almost always the case in the open marketplace. Not only does this have the potential to drive down prices, it should help keep the pace of feature innovation high, as any stagnation from one vendor could lead to lost opportunities in our fast-pace and ever changing technology industry.

&nbsp;