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.

VKernel Ships Capacity Bottleneck Analyzer

We shipped the Capacity Bottleneck Analzyer (PDF) virtual appliance.

Go download CBA and start reviewing your performance, resources, and capacity with an appliance that's quick to download.

You just configure the IP address (DHCP or Static) and then point CBA at your Virtual Center or ESX host and start collecting and reporting.

How to predict future capacity bottlenecks

Your virtual data center is growing. You are adding a ton of new VMs every week. Wouldn't it be really cool if you head a "crystal ball" that told you in how many days you will run into capacity bottlenecks and what type of bottlenecks it will be (cpu, memory, storage) ?

Now you can. Join Vkernel's beta program for Capacity Bottleneck Analyzer that will kick off in early March

How many more VMs can you fit into a Cluster, Resource Pool or Host?

Given the speed at which most admins are adding new VMs to their environment ("vm sprawl"), every admin has to figure out where to deploy the new VMs. Simply guessing about resource availability will lead to performance problems and downtime. What I am proposing here is a simple 4 step process you can use to determine how many more VMs you can fit into a Cluster, Resource Pool or a host. Here it goes

1. Select a cluster, resource pool or a host
2. Get info on available memory, storage, cpu, disk i/o and net i/o
3. Calculate an average VM footprint in the cluster, RP or host in terms memory, cpu, storage, disk i/o
4. Apply average VM footprint to every resource type to see which resource you will run out of first.That’s how many more VMs you can fit into host, cluster or resource pool

o

9 capacity bottlenecks in ESX that kill performance

I have compiled a list of "things" that can cause you to run out of capacity resources in your ESX data center and run into performance problems or even downtime:

1. Adding new VMs though uncontrolled VM sprawl
2. Removing hosts from clusters
3. HA enabling your cluster without accounting for fail over
4. Changing Fail Over Capacity setting in a Cluster
5. Increasing reservations in VMs
6. Changing Resource Pool Configurations
7. Power up many VMs that were powered off or in maintenance
8. Natural growth rates in Storage, CPU, Memory and Network utilization
9. Changes in workloads can result in Disk I/O bottlenecks

Did I miss any? Let me know abakman@vkernel.com

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