Killer VMs on the loose.

I have been hearing more and more about the "Killer VMs" - think of this as the lovechild of Virtualization and the industry term "Killer Apps".

Wikipedia has it as "is an application so compelling that someone will buy the hardware or software components necessary to run it."

Basically virtualize the "Killer App" and its becomes the "Killer VM".

This will make you visible, put your name on the map, your CIO will thank you, your CEO may even wave at you once in recognition of your stellar service.

Don't get cocky. These "Killer Apps" often have problems and are the application server than when it hiccups, goes down, causing your business pain and makes everyone go "We really should do something about that" but no one does.

Alot of IT departments may spend a ton of money on Active/Passive Clustering, etc - remember its a favorite child, it may get all sorts of resources, dollars spent on it, trying to ensure application SLA's or increase its uptime and performance.

I have seen new servers, more memory, faster CPUs, even SAN's purchased to manage "Killer Apps".

I have seen investment in high-end clustering, low-end clustering for "Killer Apps" - when at the end of the day the "Killer App" may just be a Windows 2000 Server running SQL with an application that is mission critical.

Enter VMWare, enter DRS, VMotion, HA, etc and you pick up some amazing tools to manage these "Killer Apps" and they become "Killer VMs".

Mark Brunnel writes about putting Navision and SQL 2005 into a VM, and had the v-piphany (virtualization epiphany):

"It is amazing to see VMWare running and the management and failover capabilities. For me it means the end of active passive clusters."

Mark's done some rough benchmarking and found that "VMWare is just slightly slower in posting but only 5% maximum." that's compared to the application running in Windows.

More and more people are going past their initial P2V consolidation effors, alot more are building VMs without every having a physical server, and now folks are optimizing environments, in this 2nd or 3rd phase of Virtualization, the Killer VMs are going to start showing up - these VMs will be more important than some others, require more attention, more care and feeding and better capacity management of the resources.

No CIO is going to like to hear that a VM used by 10 people took down a "Killer VM".

No CIO wants to hear that you could have prevented it but hadn't rolled out Resource Pools yet or don't have the right systems management tools to manage/monitor resource utilization.

Servers are no longer a "Resource Boundary"

One of the hardest concepts for System Administrators new to virtualization to understand is the shared resource management. VMware ESX makes it possible to share resources namely memory, cpu, storage and network not only inside a physical host, but also across multiple physical hosts. The resources are pulled together to create one massive resource pool captured in a concept called a cluster. Even resources inside clusters can be further subdivided into many Resource Pools. For admins who are only used to dealing with physical servers as resource boundaries this can be confusing, especially when it comes to planning and management of capacity. For example when monitoring or determining resource capacity, Admins must now take into consideration how all resource boundaries are affected. Looking just at physical servers is no longer an option!

Are you ready to SHARE your resources?

Sharing what? Resources? Memory? CPU? Storage?

There is an entire generation of Sys Admins now that has grown up with a distributed computing data center where one application is normally run on one server. This mostly happened because of Windows instability. Most administrators did not want to deal with trying to troubleshoot OS problems and multiple application problems at the same time. The threat of the infamous "Blue Screen of Death" defacto created this one application one server architecture. In this world admins did not have to think about or worry about sharing of resources.

Welcome to server virtualization where sharing of resources IS the primary idea. Sys Admins now will have to get used to the fact that their VM may suffer performance degradation as a result of its neighbor VM running on the same hardware and consuming a disproportionate amount of CPU and memory. So now Capacity Analysis and Capacity Monitoring becomes important again just as it was back in the mainframe days. Sys Admins now have to really pay attention to "Who is consuming what resources". Capacity Analysis is not a one time event. It is an ongoing activity. In fact many System Administrators I have spoken with are already spending a good chuck of their time troubleshooting capacity related bottlenecks in their environment.

The problem will only get worse. As organizations continue to add Virtual Machines at an exponential rate, this problem in fact will get exponentially more challenging. The unpredictability of work load management will make Capacity Analysis a required activity that will have to be performed at least daily. Just because you have used VMWARE Capacity Planner for your initial P-to-V conversion, you have to realize that it was nothing more than initial sizing. As you continue to add more virtual systems to the mix, many of the previous assumptions made by the Capacity Planner will no longer be accurate.

I love virtualization! Let me know what you think and email to abakman@vkernel.com

Alex Bakman

How to Calculate how much to Chargeback

While most agree that charging departments for computing resources consumed is the way to go, many get stuck with the question of "How do we compute what what we need to charge for Memory, CPU, Storage and Network usage. Since you have many departments that share Virtual Datacenter, how do you go about figuring out how much to charge users per every GB of memory used, or for every Ghz of CPU consumed. This is a real brain cramp!

It took us a little while here at VKernel, but we "cracked the code" on this one. We created a spreadsheet that takes into consideration your ESX hosts, storage and network devices and what you paid for them, how many user departments you have, who is using the resources, cost recovery timeframe, etc and automatically calculates rates that you should be charging your users per day for memory, CPU, Storage and Network.

As you make changes to your infrastructure simply update the spreadsheet and it will recalculate the rates. You can download the Calculator and the White Paper that describes step by step how to use it from

http://www.vkernel.com/resourcecenter/methodology/

Let me know what you think?