Problem solve Get help with specific problems with your technologies, process and projects.

Building a support system for dynamic Hyper-V environments

Organizations that aim to hide the virtual layer from the rest of IT are bound to experience app and server support issues when performance problems arise.

Moving toward virtualization means your approach to support also changes.

One mistake IT organizations often make with virtualization projects is to focus mainly on the technology and not the impact on IT during normal operations. It's not surprising since the big selling points of virtual machine environments are geared toward cost and control. The problems, however, usually involve support for the unexpected.

It is the goal of many virtual environments that people never notice a server was virtualized in the first place. Still, you need to be realistic and understand that virtualization can have an impact on even the most well-run environment. Keeping the layer of virtualization a secret will only cause confusion during a support incident.

For example, consider a support call that comes into the help desk where people are complaining about an application performance issue. The issue is escalated to the application support team, who then push it to server support before it's finally sent over to the virtualization administrators. Why did it get passed around so much? What happens is the application people take a quick look and don't see any obvious issue, and the server support people don't see anything when they look on the virtual server. They all know the server is a VM, but have no idea what would cause the performance problem, nor do they have any way to check.

The blame game and finger pointing can rise to a new level with the addition of the virtual layer. So what should you do to ensure your service delivery can support this new technology?

1. Don't hide the virtualization layer
Many virtualization groups want to avoid trouble and often feel that they can deal with virtualization in a siloed fashion. It's true that the initial response to virtualization can be one of misunderstanding for an application team, which often leads to a cloak of secrecy being built over how the virtual environment actually operates.

Instead, institute a policy of transparency. Allow the server and application administrators to view your virtual operations, including any reports or real-time data you can feed them in a self-service manner. This will help to create an understanding of how virtual statistics affect the virtual servers and applications.

2. Appropriate monitoring
It's still standard practice to monitor virtual machines for signs that performance is falling outside the established baselines, just as you would any physical server. However, the host operating system also plays a part in the performance of every single virtual machine hosted on that server. Since Microsoft doesn't really provide a way to monitor the physical host from a guest virtual machine, you'll need to gather that data from the host machine, otherwise known as the root or parent partition.

There are several sets of performance counters specific to Hyper-V and WMI calls that you can make to query the server for statistics. For example, the Hyper-V Virtual Machine Health Summary counter is a simple switch that reports the health status as either normal or critical. With the Logical Processor counter, you can monitor the number of virtual machines, the number of logical processors to physical processors, and the potential overload of the host. Providing support engineers with the ability to see this hypervisor data and map it to possible issues on the guest VM can be a vital time saver when an issue does occur.

3. Avoid too much homogenization and standardization
This may seem contradictory to the purpose of using virtual machines, but in most organizations you are not running the Google data center. You still have different requirements across your application servers, so sometimes a rigid requirement of standardization and lock-out from flexibility can cause unanticipated problems.

4. Involve your application support team in the decision-making process
The app support team often holds key information that will help you decide how to apply your application servers across multiple hosts or cluster members. For example, application servers often supply Web services that are designed to scale out to multiple machines. If you host several virtual machines on a single physical host and you run into a problem on that host, you can cut significant capacity for that application. A consultation with the application team should tell you how that application is distributed so you can make the right choice on how to distribute the virtual machines and avoid downtime.

When it comes to operations support issues, the ping-pong effect between different groups is a dangerous thing. It happens in all facets of IT, but virtualization adds another potential point in the turf wars of various IT disciplines. Yes, virtualization will reduce your budget and the number of physical machines, but understanding how it affects applications as well will lead to a fully-functioning relationship between the Hyper-V administrators and the rest of IT. Without that understanding, be ready for uncomfortable meetings about applications taking more downtime than they should and incidents getting lost in the fog of uncertain responsibility. It won't be long before the shine is taken off of what should be a positive step for your organization.

Eric Beehler has been working in the IT industry since the mid-90's, and has been playing with computer technology well before that. He currently provides consulting and training through his co-ownership in Consortio Services, LLC.

Dig Deeper on Microsoft Hyper-V management

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.