There’s always a danger these days in writing a pro or con piece about virtualization, partly because the hypervisor wars of the past few years have been so furiously vitriolic on both sides. Yet no matter which side of the war you’re on, at the end of the day you’re still managing the hypervisor you have.
With Microsoft’s Hyper-V, the most obvious management solution is its System Center Virtual Machine Manager (VMM) 2008 R2. You could call this version a minor step forward in the features it exposes to administrators. Yes, VMM 2008 R2 adds support for Live Migration, various network optimization features and Cluster Shared Volumes, among other capabilities. Many of these “new” features, however, are in fact representations of the updates to Hyper-V R2 itself.
Even with these updates, many administrators still find VMM 2008 R2’s administrative capabilities lacking in key areas that its competition already enjoys. Let me outline four of these that many admins – or I at least -- wish it supported.
Dead simple host clustering. I recognize and support Microsoft’s decision to lean on its existing Windows Failover Clustering service for aggregating Hyper-V hosts into a cluster. Even with that service’s rocky beginnings, it has evolved to become a production-worthy general purpose clustering solution. With it, you can cluster many different Windows Server roles to improve uptime.
Yet the service’s “everything-for-everyone” reach also makes it unnecessarily complex for Hyper-V host clustering. That’s a massively limiting factor for many Hyper-V implementations; with complex construction requirements and far too many knobs to turn, clustering Hyper-V hosts is simply too difficult a process.
Microsoft has already seen the value in “skinning over” its traditional clustering interface with the implementation of database availability groups (DAGs) in Exchange Server 2010. With its dead simple interface, creating a DAG is easy. But what many people don’t immediately recognize is that a DAG is in fact a Windows Failover Cluster in disguise, hiding all the complex cluster configurations behind a minimal interface.
Clustering Hyper-V hosts should be just as simple. In fact, I fear that Hyper-V adoption will continue to stall until Microsoft takes this same approach with its host clustering.
Dead simple host and guest monitoring. There is an emerging wisdom when it comes to virtual machine monitoring that suggests we should move away from percentage-based monitoring metrics (think % processor time). That wisdom suggests that whole number-based metrics are in fact a more valuable measurement of virtual machine performance (think 1150 MHz processor demand). By relying on integers rather than percentages for gauging VM performance, calculating a private cloud’s supply and demand of resources is reduced to simple addition. Yes, other transient factors are always at play, but performance utilization with virtualized servers usually hits a predictable steady state over time.
I also understand and respect Microsoft’s decision to offload deep-level monitoring of VMM to System Center Operations Manager (SCOM). Doing so means an organization’s SCOM infrastructure can handle virtual environment monitoring in a more unified way. The problem, however, is in the integration and the instrumentation. Simply put, Microsoft’s SCOM monitoring features for Hyper-V lack the depth of view necessary to truly understand VM performance. Further, they don’t expose resource supply and demand data in ways that make capacity management dead simple. Most challenging is the integration process itself, requiring a sometimes-tenuous handshake between two separate solutions (VMM and SCOM) that feels kludged together rather than like a unified solution.
I have asserted before that evolving simple virtualization to business-ready private cloud computing requires deep monitoring of VM activities, along with presenting that information in a way that’s actionable by administrators. We still aren’t there yet with VMM 2008 R2.
Cluster-aware load balancing. It was not long ago that I took an incredibly deep dive into VMM’s (in combination with SCOM’s PRO Tips) logic for determining cluster load. I was shockingly unimpressed.
Microsoft’s competition enjoys some significant longevity advantages, which means they’ve had the time to implement and tune these needed features into their products.
Hyper-V’s competition uses a series of processor and memory metrics to determine the current load on a host, along with that load’s standard deviation in comparison with other hosts in the cluster. With the competition, when the standard deviation of the current host’s load grows too large, this signals the host is overloaded in comparison with others in the cluster. What results is a series of migrations and a better-balanced cluster. While not a perfect solution, it is beautiful in its simplicity.
VMM, on the other hand, relies on a much less elegant solution. To quote from my previous article, “If host resources are overloaded in VMM 2008 R2, virtual machines can be live-migrated off a cluster host. According to a Microsoft TechNet article, SCVMM recognizes that a host is overloaded when memory utilization is greater than ‘physical memory on the host minus the host reserve value for memory on the host.’ It also recognizes when CPU utilization is greater than 100% minus the host reserve for CPU on the host.”
You have to read through this statement’s fine print to gather its meaning. Virtual Machine Manager focuses on single-host metrics for determining if that host is overloaded. If it is, VMs get offloaded elsewhere. However, (at least as I read it) there appears to be no logic that aggregates metrics across the entire cluster to determine the cluster’s balance and/or imbalance of resources. The result is what amounts to a reactive approach to load balancing, moving VMs around any time a host is overloaded rather than analyzing loads from a cluster-wide perspective.
While this simplistic load balancing approach can function well in smaller environments, it creates challenges as the number of hosts scale. Lacking cluster-wide metrics, VM rebalancing can potentially create load problems as it seeks to resolve them. To me, that’s not an acceptable solution.
Virtual machine affinity. Affinity and anti-affinity are fancy words that in essence mean, “Keep these VMs on the same host” and “Always keep them on different hosts.” Affinity rules are great for keeping chatty VMs collocated. Anti-affinity rules come in handy for ensuring your Active Directory domain controllers don’t end up on the same Hyper-V host.
In Virtual Machine Manager 2008 R2, affinity and anti-affinity rules are exposed exclusively through VMM’s PowerShell interface. While perfectly functional, managing these rules via a command line grows unwieldy over time. Pulling affinity and anti-affinity rules directly into VMM’s GUI will ease this administrative activity.
Virtual Machine Manager today represents a great effort on the part of Microsoft to create a centralized management studio for administering virtual machines. At the same time, however, it is what can almost be called a v1.5 release. Microsoft’s competition enjoys some significant longevity advantages, which means they’ve had the time to implement and tune these needed features into their products.
With the Hyper-V R2 release (and particularly the Hyper-V R2 SP1 improvements), Microsoft has significantly raised the bar in terms of hypervisor feature parity. Microsoft’s next crucial step will be to add the functionality listed above along with other critically necessary administrative conveniences to future versions of its VMM product.
You can follow SearchWindowsServer.com on Twitter @WindowsTT.
ABOUT THE AUTHOR
Greg Shields, Microsoft MVP, is a partner at Concentrated Technology. Get more of Greg's Jack-of-all-Trades tips and tricks at www.ConcentratedTech.com.