Since the introduction of vCenter ChargeBack integration with VMware vCloud Director & I hear repeatedly questions about how its Cost Models charge in a VMware vCD environment. To be honest, the question usually come in the form that vCenter ChargeBack is not calculating the cost as I expected & something wrong with it. Most of the time it turn out nothing but a misunderstanding of vCenter ChargeBack Cost Models in a vCloud Director environment. As vCenter ChargeBack Cost Models highly integrate with VMware vCloud Director allocation models, its very important to have a solid understanding of VMware vCD Allocation Models. As Duncan Epping & Chris Colotti both has explained vCloud Director Allocation Models extensively in two great blogs posts, I am going to only reference these and not cover it in this post & rather focus on the vCenter ChargeBack part of the story. Below are the two posts for VMware vCD Allocation Models:
vCD – Allocation Models (By Duncan Epping)
vCloud Allocation Models (By Chris Colotti)
Please make sure you go over one of the above posts if you still don’t have a clear understanding of the vCloud Director Allocation models before going over this post, as I am not going to cover that.
Let’s start by looking at the most common VMware vCenter ChargeBack Cost Models for VMware vCloud Director. The five most common ChargeBack Cost Models I want to start with are as below:
vCenter ChargeBack Cost Models at the VMs Level
1- VMware vCloud Director Billing Policy – Pay As You Go Fixed Charging
2- VMware vCloud Director Billing Policy – Pay As you Go Resource Based Charging
vCenter ChargeBack Cost Models at the org-VDC level
1- VMware vCloud Director Billing Policy – Reservation Pool
2- VMware vCloud Director Billing Policy – Allocation Pool
3-VMware vCloud Director Billing Policy – Overage Allocation Pool
As you will notice above I have split the VMware vCenter ChargeBack Cost Models for vCloud Director to two types that are at the VMs levels & that at the org-VDC level. I believe most of the confusion come at this part where many customers use an org-VDC level cost models, but want to set costs for different parameters at the VM level. Unfortunately this is not the way it meant to work. Let’s exploit this a bit further.
For “Reservation Pool” and “Allocation Pool” Allocation models of vCloud Director the whole org-VDC is sold as a chunk of capacity, the idea is to charge at the org-VDC level and not at individual VM level. Hence vCloud Director data collector running in vCenter chargeback sets allocations for CPU, memory and storage at org-VDC for Reservation and Allocation pool org-VDCs. Its basically you sell the customer a full chunk of resource and its up for him how he use it unless Overage is being utilized but let’s assume Overage is not being used at the moment. Let’s look at how the calculation happen in this Case:
If you are giving a customer an org-VDC with 10Ghz of CPU, 20GB of RAM, 200GB of disk then you decided that you will charge $.02/hr for 1Ghz of CPU, $.04/hr for 1GB of RAM, & $.1 per 1GB of disk. The cost of this customer per hour will be as follow:
(10Ghz * .02) + (20GB * .04) + (200GB * .1) = $21/hr
One important thing to notice of the above calculation that it does not take into consideration how many virtual machines or the size of VMs running in it while coming up with the customer cost. The cost is totally being set based on the total chunk of resource given to the customer in the shape of an org-VDC. This is very important to grasp as I have been repeatedly asked by a customer who is using an Allocation Pool or Reservation pool that vCenter ChargeBack is coming up with different numbers than when the math is done manually and the reason for about 99% of the time is that the admin is doing the calculation based on the amount of resource the customer is using to create his VMs which is totally ignored in such a model.
Another important thing to grasp that although the reservation pool and allocation pool work differently on the vCloud Director level in that the Reservation pool reserve 100% of the resources where the Allocation Pool only reserve a preset percentage of resource both of them are charged in exactly the same manner in vCenter ChargeBack where you are always charging based on allocation. One more cause for confusion on the Allocation Pool & Reservation Pool cost models in vCenter ChargeBack that if you generate a report on the VM or vAPP level under an Allocation Pool or Reservation Pool org-VDC you can get the numbers based on the VMs Specs, where if you do it on the org-VDC level you can not get these. Well, when you are generating the report at the org-VDC level vCenter ChargeBack is aware that this org-VDC is running an Allocation Pool or Reservation Pool model and it will only generate info involved in such a model in the generated report where it does not do that if you do it on a VM or a vApp under that organization as it assume you only want to generate usage or cost data for that particular element based on what ever model you choose.
At last its important to mention that there is few fixed costs (Example OS Cost) that can be added at the VM level into these models. Though to do that you will need to modify the billing Policy Expressions to include Fixed costs as it does not include that by default.
Its important to always remember when using Allocation Pool & Reservation Pool cost model then you are charging the customer for the full chunk of resource you are assigning to him if he used or not. Its very similar to the web-hosting. The webhosting company give you a certain amount of CPU, RAM, & Disk space & they charge you for it regardless of how much you use out of it. Another similar scenario is you internet connection. My ISP tell me that he will give me a 35Mbps pipe for a cost of $50/Mo. Believe it or not he will still charge me the $50/mo even if I have not used it at all. I hope this make the Allocation Pool & Reservation Pool cost models clearer.
If Charging for individual VMs is what you are looking for then the “pay as you go” cost models will be more appropriate. Utilize Pay As You Go – fixed-based–charging cost model if you intend to charge a flat, fixed fee per virtual machine; use the Pay As You Go – resource-based–charging cost model if you intend to charge based on the amount of vCPUs, memory, & storage allocated to the vAPP. As you can see now the focus of the Pay As You Go Cost models are totally focused on the VMs levels how many or the specs of the VMs. So if your plan is to charge based on how many VMs a customer utilize or on what specs these VMs have or certain fixed fees for certain features in the VMs the customer use then Pay As You Go is the model for you. Let’s take a sample quick calculation of “Pay As You Go – resource-based–charging cost model”. Let’s assume you decide that you will charge $.02/hr per vCPU, $.04/hr for 1GB of RAM, & $.1 per 1GB of disk where the customer has created two VMs as follow:
VM1: 1vCPU & 1GB of RAM & 10 GB of disk
VM2: 2vCPU & 2GB of RAM & 20GB of disk
This customer cost per hour would be:
(3vCPUs * .02) + (3GB * .04) + (30GB * .1) = $3.18/hr
As you can see the calculation in a pay as you go model is totally arousing around the VM specs & counts rather than org-VDCs in opposite to the Allocation Pool Cost model & Reservation Pool Cost Model. One more thing to mention that Instance Costs are specific to Pay as you go models in a vCloud environment & won’t work with the Allocation Pool & Reservation Pool models & that should make sense as they are totally related to the specs of the VMs.
Charging for Overage
Charging for Overage has been another area where many questions arise. Overage is meant to give the admin the ability to charge a customer a premium fee when they run over a certain limit. It is similar to what my ISP treatment, let say I get charged $50/mo for 25Mbps up to 100GB of bandwidth. If I ever go over the 100GB of bandwidth my ISP will charge me a premium fee at a much higher rate which is something you might want to do in your cloud environment. Now you got the goal of charging for Overage in vCenter ChargeBack in a vCloud Director environment let’s look at the Allocation Pool overage scenarios.
If you remember what I have mentioned earlier without overage both allocation pool and reservation pool end up being charged similarly. Though in the allocation pool you have your allocation setup higher than your reservation. Overage will give you the chance to charge the customer at a base rate while sticking with what is reserved to him & charge him a premium fee for any extra usage above the reservation and below the limit. Let’s look at the below scenario for an allocation pool with and without overage.
The customer is assigned an allocation pool of 10Ghz, 20GB of RAM, & 100GB of Disk space. where the reservation has been setup to 50% of CPU & 50% of RAM. Let’s assume the customer is using 8Ghz, & 15GB of RAM & 80GB of disk space. The pricing are set as: $.01 per 1Ghz/hr & $.01 per 1GB/hr & $.01 per 1GB of Disk, where you will charge $.1 per 1Ghz/hr & $.1 per 1GB/hr for overage.
Without Overage: The customer will be charged for the full allocation as below:
(10Ghz * .01) + (20GB * .01) + (100GB * .01) = $1.3/hr
With Overage:
(5Ghz * .01) + (10GB * .01) + (100GB * .01) = $1.15/hr
(3Ghz * .1) + (5GB * .1) = $.8/hr <== Overage cost
The total cost with the overage for this customer will be: 1.15 + .8 = $1.95/hr.
if reservation pool cost model were used, then overage will not have any affect on the calculation which will end up being exactly as the allocation model without overage as the reservation equal exactly to allocation in that case. Further, its important to note that the overage attribute is disabled by default in vCenter ChargeBack and you can turn it on globally by going to settings=>Data Collectors =>VMware vCloud Director Tab
Then change the attribute VMware vCloud Director apply overage charge on allocation pool vDC to true as in the below screenshot:
You can as well enable overage for a certain vDC rather than globally by going to the hierarchy manager & right click the Org-VDC you want to enable overage for then choose manage attribute then change the EntityLevelOverageFlag to true as the below screenshot. I actually rather this method on enabling it globally as it give me control on where I want to enable overage and where I don’t want to do so.
Okay that all for now. I hope this help you better understand vCD allocation models and how they are treated by vCenter ChargeBack Cost models & how Overage Work.
Please note the cost for CPU, Memory, & disk I have used in my examples have only been used for the ease of calculation and not a great example to use in your real environment. For that you might want to check the vCenter ChargeBack Base Rate Calculator.
I hope this help some one, & sorry if I have given you an overdose of VMware vCenter ChargeBack 
.
