Hyper-V Reviews

Replication is configured on a per virtual machine basis. Virtual machines running on Primary site Hyper-V servers (or Hyper-V Failover Clusters) are configured to replicate to Replica servers (or Replica Failover Clusters) at remote sites.
1. In Hyper-V Manager, in the Details pane, Click on a virtual machine
2. With a virtual machine selected, Right-click and choose Enable Replication. This starts the Enable Replication wizard
3. In the Specify Replica Server screen, enter either the NetBIOS or the Fully-Qualified Domain Name (FQDN) for the Replica Server in the Replica Server box. (Note: If the Replica server is a Failover Cluster, ensure the connection point for the Hyper-V Replica Broker is used). Click Next

4. If Remote WMI is enabled, then Hyper-V Replica automatically fills the port and authentication settings
5. In the Choose Replication VHDs screen, deselect the disk(s) you do not want to replicate for the virtual machine and then click Next
6. Replication changes are sent to a Replica server every 5 minutes. In the Configure Recovery History screen, make selections for the number and types of recovery points to be sent to the Replica server. If Only the latest point for recovery is chosen, then there will be only the parent VHD that is sent during Initial Replication and all changes are merged into that VHD. If Additional recovery points is chosen, set the number of desired additional recovery points (Standard Replicas) that will be saved on the Replica server. The final selection in this screen, Replicate incremental VSS copy every : (available only if Recovery History is enabled) can be used to save Application-consistent Replicas for the virtual machine on the Replica server. After completing the selections, Click Next

7. In the Choose Initial Replication Method screen, several methods can be used to perform an initial replication for the virtual machine to the Replica server. The default selection is to Send initial copy over the network. This starts replication immediately over the network to the Replica server. If immediate replication is not desired, it can be scheduled to occur at a specific time on a specific date. If the administrator does not want to consume the bandwidth due perhaps to the large amount of data that needs to be replicated, he can choose Send initial copy using external media. This method copies all the virtual machine data to a portable storage device that can then be sent to a Replica site and the initial replication can be completed there by importing the data. The final option available to an administrator is Use an existing virtual machine on the Replica server as the initial copy. A restored virtual machine or snapshot of a virtual machine on the Replica server will be used as the initial copy. Make a selection and then Click Next

8. In the Completing the Enable Replication Relationship Wizard, review the information in the Summary and then Click Finish
9. A pop-up dialog box is presented indicating replication was successfully enabled for the virtual machine. In the dialog box is a Settings button that can be used to configure the network the replica virtual machine will connect to on the Replica server. This can be useful because the replica virtual machine is not connected to any network on the Replica server by default
The Enabling Replication process will start and should complete successfully (i.e. a virtual machine is created on the Replica server and delta replication commences. If the Replica server is a Failover Cluster, the virtual machine is made highly available). If any errors occur, refer to the troubleshooting section later in this document.

Once the replication relationship is established and if Send initial copy over the network was selected (Default setting), the Status column for the configured virtual machine will indicate Sending Initial Replica. Progress as a percentage of the total replication is also displayed.
Note: If a virtual machine is being replicated to a Failover Cluster (using the Hyper-V Replica Broker), a highly available virtual machine is created in the cluster. This allows the replica to be migrated to other nodes in the cluster if needed.
If Send initial copy using external media was selected, the Status for the virtual machine will indicate an Initial Replication in Progress. In this case, the progress reflects the copying of the virtual machine files to a location other than the Replica Server (perhaps a portable storage device) so the files can be transported to the Replica server location and then the Initial Replication can be completed by importing the files on that server. Once the import process completes, the Replication State for the virtual machine in the Primary Site will reflect a new Replication State of Replication Enabled.
If Use existing restored virtual machine as initial copy was selected, the virtual machine files restored from a backup on the Replica server will be used for Initial Replication (IR). Before delta replication actually begins, a quick resynch is executed.

Hyper-V Replica implements the standard Hyper-V virtual machine folder structure on the Replica server in the location specified when the Replica server (Replica Failover Cluster) is configured. A Hyper-V Replica folder is created as the root folder in the specified location. Under the Hyper-V Replica folder is a series of subfolders as seen here -

NOTE: The Snapshots folder is not created unless Recovery History is configured for the virtual machine.

The folders support the necessary files for each virtual machine configured to replicate with the Replica server. The virtual machines are identified by Globally Unique Identifiers (GUID) as seen here -

For my first post here on Hypervisor Agnostic, I thought it would be appropriate to open up with a debate that I’ve been sucked into as of late due to a project I’ve been involved with at work. Has Hyper-V finally reached the point that it can go toe to toe with VMware as an enterprise hypervisor product? Or is Hyper-V merely an entry level solution for small businesses that lack the budget to invest in VMware? My answer is yes, Hyper-V is an enterprise product, but is it right for your enterprise? The answer to that is a little more complicated.

To appreciate where Hyper-V is today, you have to understand where it began. Microsoft first entered the virtualization market when MS bought the Virtual PC product line from Connectix back in in 2003. Virtual PC was originally a virtualization program for Apple Macintosh computers that ran various x86 versions of Windows (and other x86 OSes) on MacOS. Today, that doesn’t seem like anything special, because modern Macs can dual boot Windows with no problem. But back in those days, Macs and “IBM clones” were based on entirely different processor architectures, and getting Windows to run on a Mac was no small feat. To be fair, getting Windows to run stable on any hardware in the 90s was a minor miracle, but I digress. The point is, Connectix had a pretty decent little virtualization engine for the time, and MS wanted it for their own. From Virtual PC came Virtual Server, which was designed to run on Windows Server platforms, and run other server operating systems. It was designed to compete with VMware Server, another Type 2 hypervisor (a virtualization engine that runs as a program within a conventional operating system). But Type 1 baremetal hypervisors like VMware’s ESX were starting to become affordable, viable solutions, and Type 2 platforms started to become relegated to desktops rather than data centers.

So in order to get in on the baremetal hypervisor party, Microsoft announced that Windows Server 2008 would include Hyper-V – a free, baremetal hypervisor system that offered better performance than Virtual Server. Hyper-V ended up being a separate download from the RTM version of Server 2008, and it was somewhat underwhelming when it was released, being years behind what ESX and Citrix Xen were capable of. There was no way to migrate a VM from one node to another without downtime, VMs in a failover cluster had to be placed on their own LUNs, guest operating system support was very limited, as were the specs of virtual machines. 2008 R2′s release of Hyper-V improved in many of these areas, offering clustered storage, live migration of VMs, and a slightly expanded list of guest operating systems supported.

But it was Hyper-V 2012 that Microsoft really came out swinging, offering specs that (on paper at least) out-scale VMware, improved live migration, along with storage migration (previously only available with System Center Virtual Machine Manager), a completely rebuilt networking stack, and several other features that helped to close the gap between Hyper-V and VMware.

But the gap is still there, and that is the the point of this initial blog post. I’ve spent the better part of this past year working with Hyper-V 2012, and there are some things I absolutely love about it, and some things I loathe. Here’s my run down of what’s good, and what’s bad.

Scalabiltiy

MS advertises that Hyper-V can support 64 nodes in a cluster, as compared to VMware’s 32 nodes. They also claim Hyper-V nodes can support 4TB of RAM, 320 logicial processors, and can support VMs with 1TB of RAM. To me, speccing out a hypervisor like that seems somewhat ridiculous. I’m much more of a fan of “scale out” than “scale up” – I’d rather have 12 nodes in a cluster with 256GB of RAM than 3 nodes with 1TB each. Sure, Hyper-V can support 64 of those nodes with 1TB of RAM. I don’t, however, want to be the guy who has to handle maintenance on that cluster, and wait on all the VMs filling up that 1TB of RAM to migrate from node to node when I want to install Windows updates.

Still, it is great that Hyper-V finally supports VMs with decent specs. I don’t foresee myself ever needing to give a VM one terabyte of memory, but it’s a lot better than 32 or 64GB, and the ability to add more than 4 virtual CPUs is a much needed improvement. Combine that with a new virtual hard disk format that offers much larger sizes, and Hyper-V VMs can be built to a decent scale. That does, however, leave the door open for a lot of overbuilt VMs, but that’s another rant for another day.

Clustering

This is one area where Hyper-V is really positioned to eat VMware’s lunch. If we compare apples to apples, ie free product vs free product, Hyper-V has one significant advantage over VMware’s free ESXi offering: free Hyper-V can be part of a Windows fail over cluster. Free ESXi is standalone only – and has a pretty limited RAM cap to boot.

So if you want a cheap, highly available virutalization solution, Hyper-V is the way to go. The freebie version of Hyper-V (meaning the standalone, downloadable version – not enabling the Hyper-V role in Windows 2012) is not feature limited compared to its Windows Server brethren. To get HA/fail over capability in VMware’s product, you’re going to spend several thousands of dollars.

But the drawback to this is that it’s built around Windows Failover Clustering, which has it’s own set of issues. First of all, let’s not forget Windows cluster’s reliance on Active Directory.

If you virtualize all your domain controllers, and have some kind of network issue that prevents a node from finding a domain controller, hilarity will ensue, and by hilarity, I mean a bunch of VMs dying/failing over. Second, management of many clustered nodes is possible without System Center Virtual Machine Manager, but it is controlled chaos at best. Once Hyper-V nodes are clustered, you should generally do all node & VM management from the Windows Failover Cluster management console if you’re not using SCVMM. However, MS didn’t include a way to manage Hyper-V networks from the Failover Cluster manager, so you still have to do that through the standalone Hyper-V management console, and do it one by one. Yes, you can script it through PowerShell, and from what I can see, PowerShell seems to be the only “one stop shop” for dealing with Hyper-V. Without PowerShell, you’ll find your self bouncing back and forth between Windows control panel, Hyper-V manager, and Failover cluster manager in order to handle most day to day tasks. It’s do-able, but it’s ugly. VMware’s management is much more streamlined and intuitive.

Live Migration vs. vMotion

vMotion is the feature that allowed VMware to take over the virtualization world – the ability to move VMs from node to node with no downtime was huge, and no one else ever figured out how do it quite as well, or as fast. But there are some limitations – you can only do 4 concurrent vMotion operations per host in 5.1 on anything less than 10GB network links. With a 10GB NIC, you can do up to 8 per host. MS took the “let the administrator decide” approach with Hyper-V 2012, and you can now set the concurrent number of live migrations to whatever you want. Off the top of my head, I believe Hyper-V 2008 R2 only allowed on live migration at a time, so this is a huge improvement.

That said, before you think you’re going to team a couple of 1GB NIC ports in your Hyper-V host and crank the max number of migrations up to 10, 15, 20, or beyond, keep in mind that there’s a very good reason VMware sets the limits they do on vMotion. There’s more to the equation than just the network here – host memory, storage I/O, andCPU usage on host are all impacted during migrations. So, take a cautious approach to this, and steadily increase the live migration count on your Hyper-V hosts rather than deciding right off the bat that 12 is a great number to start off with.

That said, if you have a dedicated live migration network with decent bandwidth, and your hosts can handle it, 10 simultaneous live migrations at a time can significantly decrease your cluster maintenance times.

Resource Handling

This is one of those Coke vs Pepsi, Ford vs Chevy, Mac vs PC type debates. VMware zealots absolutely hate the fact that Hyper-V does not allow memory over commitment, and view it as a sign of Hyper-V’s inferiority. Hyper-V fanboys think that handing out resources you don’t have is a bad thing, and that Hyper-V’s dynamic memory is the way to handle fluctuating memory demands. This is one thing I am 100% on the Hyper-V side of the fence on. Look, it’s great that VMware doesn’t have any hard and fast limits on resource assignment. It’s great that DRS can see that a host is getting low on memory, and can move a memory hungry VM to a host with more free memory. But sometimes, the the cluster ends up over committed, a node goes down, and there’s no hosts with resources to satisfy those now homeless VMs. Or, an admin set the cluster to allow VMs to power on even if the resources aren’t there. If the memory isn’t there, and VMware can’t find any VMs that are hoarding memory they’re not actually using, then you end up with VMs swapping their RAM to disk. Outside of a critical productions system being down, a critical production system swapping RAM to disk is pretty much my worst case scenario. It’s ugly.

Hyper-V allows you to assign a startup value for a VM’s RAM, as well as a minimum/maximum value. When a VM reaches a defined threshold, it will request more memory from the host, until it reaches the maximum value. When it’s not using the RAM, it will release it until it reaches the minimum value. Yes, this requires a bit more management overhead. But this is one of those things I’d rather have some degree of control over than just leaving the hypervisor to its own devices.

Guest Operating System Support

This is one area where VMware runs away with. If you’re a primarily Windows shop running current versions of Windows, then Hyper-V’s got you covered. But if you’re running any Unix-like servers other than a very narrowly defined subset of popular Linux distros, Hyper-V can’t do much for you. And, of those supported Linux distros, you’d find some features like dynamic memory, are Windows exclusive.

And if you want to run archaic versions of Windows, you’re out of luck on Hyper-V as well – you’re limited to what MS currently provides support for, which is generally 2 versions behind whatever the latest version is. But if you feel the need to run Windows 3.1, Windows 98, or Windows 2000, the VMware’s got your hookup.

I know, surprise surprise – the Windows based hypervisor is geared toward Windows guest OSes. But if Microsoft really wants Hyper-V to make a dent in the enterprise, they need to come to grips with the fact that some companies run other operating systems that are not Red Hat, CentOS, SuSe or Ubuntu.

Wrapping It All Up

So as of September 2012, with the release of Windows 2012 R2 next month, Hyper-V has supplanted Citrix Xen as the clear number 2 hypervisor platform. in my mind. It can do at least 90% of what VMware can do, at a fraction of the cost. But is that last 10% worth the price?

For small businesses, and smaller enterprise customers that are running primarily Windows in their server rooms and data centers, Hyper-V is priced to move, even if you tack on the cost of SCVMM to manage it – pretty much a must for larger clusters. At the high end of the scale in heterogeneous environments, VMware is still the king of high availability and load balancing, and management is much more streamlined. Even with SCVMM (which brings an entirely new set of headaches, but again, more on that at another time) the thought of trying to manage a 64 node Hyper-V cluster makes my head spin.

So yes, Hyper-V is there. But VMware’s not going anywhere any time soon.

Disclosure: The company I work for is partners with several vendors - http://www.latisys.com/partners/strategic_partnerships.html