In-Depth

Assessing Your Virtual Fitness

Ready to commit to a virtualized environment? Take a step back and use this quick guide -- and PerfMon -- to help you identify your current environment's strengths and weaknesses. (First in a series)

• By Greg Shields
• 05/31/2007

So after a lot of cajoling and justification, you've finally got the funding to start your virtualization rollout. So it's time to start dropping CDs into drives and clicking buttons, right?

Possibly not.

"Forty-four percent of companies are unable to declare their virtualization deployments a success," declared an announcement by CA last March. The reasons for this large failure rate, according to CA, are attributed to the inability to quantify the ROI associated with the move to virtualization. Key factors for a successful project were listed as the ability to measure performance within the virtualized environment, diligent inventory of server assets and load distribution, and a thorough investigation of available technology solutions.

So, have you done your homework to ensure that the virtualization technology you want is the best fit for your organization? Have you completed pre-rollout engineering to verify that your servers will perform well inside the virtualized environment? If the answer to either of these questions is "no," then you may be setting yourself up for a virtual failure.

Performance is Key
The reason why virtualization works is because Windows servers are by nature lazy beasts. The industry average on server workloads shows that the majority of Windows servers rarely use more than three to five percent of their available processing power. This means your servers pass the time by idly flipping bits within the System Idle Process 95 to 97 percent of the time.

The problem is that while most servers behave in this way, not all do. One of the most critical components of any virtualization rollout is the assessment process that validates which servers play with each other when virtualized. Also, many attached peripherals, like serial and USB ports, don't work well in the virtualization environment. Ensuring that the host servers you've purchased can handle the load of your virtual server needs is of critical importance.

Completing a pre-rollout assessment of physical server performance is critical to ensuring that servers, once virtualized, don't perform worse than before. Part of this means dusting off our old friend, PerfMon, and setting up performance counters on the servers you plan to virtualize. As you probably remember, there are literally hundreds of counters that could be enabled with PerfMon. But, for the purposes of virtualization, only a few are critical.

Counter Intuitive
Counters should be run for at least two weeks, but preferably up to a month. The reason for this is that for most businesses, one month incorporates that company's business cycle. So, setting up counters to run for a month ensures that you capture the slow periods as well as the critical high-use, end-of-the-month period.

Here are some counters you should consider enabling. For any of these, if the counter's resulting performance for any server is significantly higher than on other systems, it may indicate that that server won't play well when squished together with others in the virtualization environment:

Disk\% Disk Time
If disk time is high, then that server likely does a lot of reading from and writing to its hard disk subsystem. Since virtualization environments encapsulate whole machines into single files, a high disk time counter can mean an excess of writes to its disk file, potentially becoming a performance bottleneck.

Memory\Pages/sec
When the processor is looking for data that doesn't reside in physical RAM or when the server needs to move unused data from RAM to disk, this increases the metric for Memory\Pages/sec. A high counter here could indicate often-changing processes or workloads that require lots of dynamic data. Since the physical RAM on a virtual machine is also just a file on disk, an overly high counter here could signal a potential performance concern.

Physical Disk\Current Disk Queue Length
Related to both of the above counters, if your server is reading and writing to its disk so much that its disk subsystem cannot keep up, you will see a high Current Disk Queue Length counter. As with the previous three counters, the disk-based nature of virtualization lends itself toward the potential for disk bottlenecks. Not virtualizing servers that are disk-bound may be necessary for the total performance of your virtualization environment.

Processor\% Processor Time
The processor in each virtual server is a component of the physical processors on the host. Most of what virtualization software does is schedule physical resource use based on the needs of each virtual server. So, if you are seeing servers with a high Processor Time, then that server is constantly needing the attention of its processor. That constant need could prevent other virtual servers from getting their fair share unless you establish resource limits on the host -- in the end, it slows everyone down.

System\Processor Queue Length
If you're seeing a high percentage Processor Time metric, you may also see a high Processor Queue Length metric as well. This metric deals with a processor's ability to "keep up with the load." To complicate things, it can also mean that the hardware of your physical server is not good enough to support its hosted applications. So, keep an eye on this metric.

If you see a high count for this metric, but you know your physical server is too old and slow to support its applications, you may improve performance by moving to virtualization. But, if you see a high count on a fast server, it could indicate that that server is not the best candidate for virtualization.

System\Context Switches/sec
A context switch is when the processor swaps out the thread that it's currently processing with another. Your processor does this all the time, as it's a part of its ability to multitask. But, when this number is very high, that's an indication of too many processes vying for attention of the processor. Where you usually see a high context switch count is on Terminal Servers or servers with very old applications. Because of the high process count on servers like Terminal Server and Citrix, they can sometimes not be good candidates for virtualization.

System\Threads
The thread count on a system directly relates to the number of things the processor needs to accomplish. Lots of threads potentially means lots of context switches to process them all. Like with high context switches, a high thread count can also mean a well-used processor and a suspect virtualization candidate.

Memory\Available Mbytes
Unlike the other counters, a high Available Mbytes count can be a good thing. This means that your system isn't using much of its installed RAM. Where this counter comes in handy is in right-sizing the RAM assigned to your virtual machines. Typical physical machines have too much RAM installed, which means much of it goes unused. This happens because RAM prices are cheap at the time you buy the server, but more expensive later on. So, many administrators over-spec their servers with high amounts of RAM.

In the virtualization environment, you want to conserve RAM as much as possible so it can be used by other virtual servers. A good rule of thumb for the starting amount of RAM a virtual server needs is to subtract the amount of physical RAM from your available Mbytes and then add a little bit for breathing room. So, if you have 2GB of RAM in the server and your Available Mbytes shows 1024 megabytes, then you might start out by giving that server 1GB and working from there.

You've Got Metrics. You're (Almost) Ready
So, now you know where to start before you ever drop a CD into a drive to build your first virtual server. In the second part of this series, we'll talk about the options you have for virtualization software. All have their own pros and cons. And some you may not be aware of might be a better fit for your environment than you know!