Getting a bit drunk on enterprise dollars.

It's official - Gartner's Thomas Bittman thinks VMware might be drunk.

Denise Dubie has a great article on virtualization management capabilities and a great quote describing the upcoming battle between VMware and Microsoft for the x86 virtualization market, he is quoted as saying:

"The enterprise is going to be very leery of Microsoft, but the on-ramp to VMware is a bit steep for small businesses. VMware doesn't want to lose that potential business, but the company was getting a bit drunk on enterprise dollars," says Thomas Bittman, Gartner vice president and distinguished analyst.

The abundance of enterprise dollars spent on virtualization is because virtualization fixes so many problems, reduces power, reduces physical requirements, makes x86 hardware more efficient, increases uptime, allows resource management at the OS workload level, etc.

One of my favorite reports is one that IDC did in 2006 – it depicted– IT investment to be higher spending in Year 1 on a VMware / virtualization project but that in Year 2 and Year 3 and possibly Year 4 – IT departments would avoid spending on server hardware – you would just fill up the empty capacity of the system you built in 2006.

It looked good on paper, spend more now, avoid spending later.

Unfortunately, multiple issues caused IT departments to run out of capacity, VM sprawl occurred, single core and dual core servers could not hold as many VMs as the equivalent quad core servers.

Often P2V migrations went unchecked, servers have excess CPU capacity but not enough Memory, VMs are consuming too many resources and as a result enterprises are oversizing virtualization projects or not driving up VM density to get the biggest bang from their investment.

Avoid the hangover from “getting a bit drunk” and having to purchase new hardware, more memory, bigger servers, etc. by getting a resource management tool in place and understanding what resources your VMs are using and where you have capacity in virtualized environments.

Capacity Planning for ESX is a multi-dimensional challenge

Windows Admins listen up. Your world has changed. No more one application running on one Windows server where none of your capacity resources were shared. Once you virtualize your servers, they have to share memory, cpu, storage, network bandwidth, disk i/o, network i/0, etc, with other VMs running on the same hardware. Capacity planning which was a non-event in the Windows world is now a must do, otherwise you will run out of capacity and experience performance problems or even worse - downtime.

Capacity Planning is a multidimensional problems. To do it correctly you must take into account literally hundreds of variables. Here are some of them:

- how many VMs do you deploy?
- where are you going to deploy them
- how much resource to allocate to them
- what happens if you want to change hardware
- will you violate any configuration constraints?
- do you need another host?
-what resource will you run out of first? memory? CPU, Storage -- and where?
- how many more VMs can you fit into each cluster?
- what happens if VMs get vmotioned?
- will you violate DRS affinity rules?
- what configuration constraints will you violate?
- will DRS work?
- will HA work?

I can go on and on. I hope you see just how complex capacity planning has become. As VM density on hosts continues to increase, capacity planning in VMware will become even more critical, because every physical server becomes more business critical and failure is not an option. Systems Management is fun again!!

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

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!

How many new VMs are you adding per week?

How many new VMs are you adding per week? This is very important question, because it has major implication to capacity availability in your ESX data center and ultimately performance. Every VM you deploy will consume cpu, memory, storage and network resources. It will also add additional disk I/O. It is easy to see how, if uncontrolled, you can quickly run out of resources and develop capacity bottlenecks. Of course the trick is to figure out which resource you are going to run out of first? Will you hit the bottleneck in memory, cpu, storage, disk i/o or network? The answer is it really depends on your environment, but in most cases the first bottleneck is memory. Why? Remember you were able to virtualize servers, because they were under utilizing CPU. That is what enabled you to combine 8+ plus servers on one piece of hardware. When you think about memory, it is a different story. Just because your servers are now virtual, it does not mean they are consuming less memory. Hence that's why in most environments the first capacity bottleneck is memory. What do you think the second capacity bottleneck you are likely to hit? Let me know at 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