B-Hive acquisition is a real smart move for VMWARE

Since the dawn of computing when it comes to performance management the most critical element is the user. It does not matter what performance metrics say inside the Virtual Center. It is all about how your users perceive the performance to be. Is it fast, Ok, too slow. It is not about the metrics. At the end of the day it is a qualitative experience. As David Marshall
correctly points out in his coverage of the news, the cool factor here is that now VMWare will be able to granularly break down where the time in application response is being spent. Is it in the network, database, application? When combined with vmotion, a vm could be moved to another host based on the analysis of where the problems are. If it is a network problem, move vm to another segment closer to ens users. If it is a host capacity issue, move it to another host where more capacity exists. The angle that really excites me is the ability to monitor more granularly down to the end user level. We would be able to answer how much resource is being utilized by a given user. This can be used in chargeback, capacity management etc. I hope to see Vmware publish this API in the near future!!

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?

Charging Customers for ESX Resources Should Be Fair

Many organizations are trying to figure how to do chargeback in a virtualized environment. For technical folks it is not an easy task. They understand the feeds and speeds but don’t know how to translate Gigabytes and GHz into dollars and cents. Conversely, accounting types understand cost recovery, but can’t quiet grasp this virtualization “thing”.

It is actually not that hard. As IT embraces “utility” or “on demand” computing, it can borrow from many lessons learned by companies who provide us with electricity, oil and gas. As every consumer knows, your utility company charges you for the amount of utilities you consume. If you use more you have to pay more and conversely if you use little you pay little. This approach is fair and easy to understand

Many initial attempts at chargeback are based around charging a flat rate per VM. It goes something like this. My server costs me X dollars and I can approximately host 8 VMs on a dual processor machine therefore I should charge every client X/8 per VM.

While simplistic, this approach is flawed in many ways:

1. We all know that VMs consume vastly different amount of resources (cpu, memory, storage, and network). A busy MS Exchange server supporting thousands of users is consuming a lot more resources then an old application server used by a couple of people. It is simply unfair for IT to charge the same price to all users.
2. A flat per VM model does not capture many other costs associated with running a data center In addition to consumable resources, IT must recover for software licenses, electricity and cooling, administrative cost and many other expenses. While some of them are “fixed” expenses, many are variable and must be adjusted for each billing period
3. Remember the original reason why many application servers were virtualized in the first place – they were underutilizing resources or ran on old hardware that was getting impossible to support. These servers consume hardly any resources and users wanted to save money by virtualizing them. To turn around and charge the users a lot of money for these underutilized servers is not right.
4. The fact is that most VMs are shared applications used by many departments. Some VMs are used by many while others are dedicated to a particular group. Furthermore to say that all departments use VMs equally is not based in reality. For example, take SAP. I am sure that people in finance spend a lot more time in SAP then people in IT. How do you account for this uneven usage between departments? Flat model breaks down here again.
5. Here is another problem. In dynamic utility computing, resources are allocated on demand. If you need more capacity for a business application, another VM gets launched and consumable resources get allocated for it on demand. How would you keep track of resources in this scenario. Again per VM flat charging model breaks down

The only conclusion one can draw is that chargeback needs to be based on consumption of resources and services. That way departments only pay for resources and services they actually use. Life is not always fair, but maybe at least in the new Datacenter it can be J

Let me know what you think.

Alex Bakman abakman@vkernel.com