Nope. Wasn’t under the couch. In fact it turns out it wasn’t even missing, it’s just been overlooked and might already be in your data center.

As more organizations continue to make virtualization a core part of their overall application deployment strategy they are finding challenges associated with managing and, apparently, optimizing their newly created heterogeneous infrastructure. Kevin Fogarty, in “10 Virtualization Vendors to Watch in 2010”, writes of some of the challenges with virtualization to come in the next year. One of those challenges is, apparently, optimization of resources across physical and virtual assets, at least according to Mark Bowker of the Enterprise Strategy Group.

"Anybody who can fill the gaps the big guys don't in helping virtualization admins provision and control their infrastructure is worth a look," adds Mark Bowker, virtualization specialist at Enterprise Strategy Group. "The real missing piece, though, is the ability to optimize performance across both physical and virtual assets."

Later, Kevin addresses the challenges associated with capacity planning in a virtualized environment.

In the virtual world, however, capacity management is something of a black art -- not because few people have thought of it, but because few have built tools to look at both the physical and virtual servers and see how many of one will overwhelm the other. VKernel's product works on both VMware and Microsoft's Hyper-V. Without detailed capacity planning based on real data -- not imagination -- large-scale virtualization of production systems is not practical, according to Chris Wolf, analyst at The Burton Group.

One of the easiest and most effective ways to address the challenge of optimizing performance of heterogeneous environments comprising both physical and virtual assets is to optimize the applications being delivered by those assets. Optimizing the application means making more efficient the way the application and its application stack, i.e. the web and/or application server, makes use of compute resources. Doing so means a single virtual machine increases its capacity while lowering its resource requirements, which can  translate into a higher VM density.

What seems to be ignored – either purposefully or accidentally – is that applications and their infrastructure stacks are the same whether deployed on a virtual machine or a physical server. For the most part the application doesn’t change, just the number of layers between it and the server. What’s necessary to optimize both resources, then, is to attack performance issues that are common to both models, i.e. those related to TCP, HTTP, and application-specific protocols. If you can optimize connections and application behavior through better resource management at the protocol level, leveraging caching when available, and compressing only when it will be beneficial you can significantly improve the efficiency of the platform – virtual or physical – such that capacity is increased. And because you’re optimizing components common to both deployment models, it doesn’t matter whether those resources are “virtual” or “physical.”

It’s also true that it is possible to instruct application delivery solutions to leverage physical and virtual assets based on their unique properties and capabilities. For example, if a virtual resource has a capacity that is half that of a physical resource, the application delivery solution can certainly be configured in a way to take that into consideration when determining what resource is best suited at the time the request is received to respond. Optimizing the distribution of requests across physical and virtual resources should not be overlooked especially if the environment is heterogeneous both in type of resource (physical or virtual) and capacity (maximum resources available). A poorly chosen load balancing algorithm as a means to distribute requests, for example, can make even more inefficient a heterogeneous environment. But a well-chosen algorithm can significantly increase performance and overall capacity and make more efficient the entire application infrastructure, whether virtual, physical, or both.

Part of the problem with capacity planning for applications is, certainly, ignoring the overhead associated with virtualization. The hypervisor is, after all, still an application and requires resources. It is the “abstraction layer” between the virtual machines and the underlying operating system and hardware and all the “virtual” activity must be channeled through it, which is going to consume resources that will not be available to applications. In other words, a virtualized server will never provide 100% resource capacity for applications, and this needs to be considered when performing capacity planning. Microsoft, for example, notes in a TechEd Europe presentation, “Microsoft Exchange Server Virtualisation: Does It Make Sense? [UNC03-IS]”, that the “hypervisor adds processor overhead” citing the hypervisor consumes an approximate ~12% of processor resources in its own Exchange 2010 testing. Benchmarking tests conducted by VMWare on web servers, too, indicate a varying amount of hypervisor overhead (~16% at its highest) depending on configuration and resources available [Consolidating Web Applications Using VMware Infrastructure, PDF, VMWare].

There’s nothing anyone can really do about hypervisor overhead right now. Virtualization vendors are working with hardware vendors and “virtualization aware” solutions will at some point address much of this overhead. But still, some overhead has to exist when deploying hypervisor-based virtualization solutions because, well, it’s part of the solution. That means when you’re looking at capacity you must take into consideration that overhead and subtract it from the available resources you can provision to your applications. That shouldn’t be a problem as capacity planners have long held that you never plan for 100% capacity anyway. But it still must be accounted for and addressed. One of the ways to offset the loss of resource capacity associated with a hypervisor is to make the applications that will be run atop the hypervisor are as optimized as possible. If you can gain more through optimization than you lose in associated overhead, you win.