Over the last two weeks I received multiple questions about the VMware vCloud Director (vCD) Allocation Models. vCD has three different type of allocation models which are used to allocate resources to a tenant. We will first reiterate some of the basic concepts of VMware Cloud Director before we dive into these allocation models.
vCD is an abstraction layer. vCD is a layer on top of vCenter and abstracts all the resources vCenter manages. All these resources are combined into large pools for cloud tenants to consume. (Read Frank’s excellent article on these resource groups.) Within VMware vSphere clusters and resource pools are used as resource containers. As a cloud tenant is unaware of the technology used underneath vCD has introduced the concept of Virtual Data Center’s (vDC).
There are two different types of vDC’s:
- Provider vDC
- Organization vDC (Org vDC)
A Provider vDC is a pool of CPU and memory resources combined with the storage resources you selected. A provider vDC can be a VMware vSphere Cluster or a Resource Pool and a provider vDC is the source for Org vDCs. Org vDCs are used within vCD to partition Provider vDCs and to allocate resources to an organization. vCD uses regular vSphere Resource Pools to partition these resources. So each Org vDC corresponds with a resource pool on the vSphere layer. So what is this Allocation Model that we will be discussing? Where does the Allocation Model come into play?
An Allocation Model is defined on an Org vDC level. The Diagram below depicts a scenario where four Org vDCs have been created in a single Provider vDC. The Provider vDC has a 1:1 relationship with the cluster in this case.
Allocation Models
Allocation Models within vCD are used to determine how resources are allocated to the Organization vDC and more than likely how your customer will be charged for these resources. Currently vCD has three different types of allocation models. These allocation models are listed below, with the original description provided by vCD.
- Allocation Pool
Only a percentage of the resources you allocate are committed to the organization vDC. You can specify the percentage, which allows you to overcommit resources. - Pay-As-You-Go
Allocated resources are only committed when users create vApps in the organization vDC. You can specify the maximum amount of CPU and memory resources to commit to the organization vDC. - Reservation Pool
All of the resources you allocate are committed to the organization vDC.
Each allocation model has its own characteristics. These characteristics can be placed in two categories:
- Virtual Machine Level
- Resource Pool Level
The distinction between each of the Allocation Models is how resources are allocated or to use vSphere terminology how resources are reserved or limited. In order to guarantee resources to a VM or to an entire pool vCD will set a reservation. To avoid extreme contention vCD will also cap your resources by setting a limit. These reservations and limits will be set on a VM or Resource Pool level depending on the chosen allocation model.
For each allocation model shown in the screenshot below the characteristics will be broken down in the following sections.
Allocation Pool
This is the default model, the Allocation Pool. This model allows you to specify the amount of resources for your Org vDC and also specify how much of these resources are guaranteed. Guaranteed means that a reservation will be set and that the amount of guaranteed resources is carved out of your Provider vDC. The total amount of resources specified is your upper boundary, also known as your resource pool limit. I think a diagram will explain it a bit better in this case:
Characteristics
Each model as stated before has very specific characteristics. Each of these are listed below:
- Pool of resources of which a percentage will be guaranteed
- A reservation will be set to guarantee resources on a resource pool level
- By default the resource pool reservations on CPU is 0% and memory 100%
- Tenant has a guaranteed set of resources and has the ability to burst to the upper limit
- VM Level characteristics
- No reservations or limits set on a per VM level for CPU
- Reservations set on a per VM level for memory. This reservation is based on the percentage of guaranteed resources
These characteristics are more in detail explained in the following example.
Allocation Pool example
In the example below the tenant requested 10GHz of CPU resources with a guarantee of 25% and 10GB of memory with a guarantee of 100%.
Note that the default for CPU is a 0% Guarantee which has been changed to 25% on CPU as requested by the tenant. Also note that you can specify the maximum amount of VMs that can be deployed in this org vDC. This will also help you restrict the level of over commitment and will be discussed later.
These settings on a vCD level result in a resource pool with a reservation of 2500MHz and a limit of 10.000MHz. As vCD describes it, 2500MHz are guaranteed and the customer will have the ability to burst up to 10.000MHz. The resource pool that is created and its properties are shown in the below screenshot.
As described in the characteristics section no CPU reservation or limit is set on a VM level which is shown in the following screenshot.
This is different on memory however. On memory both a reservation and a limit has been defined. The limit always equals the provisioned memory and the reservation equals the guaranteed memory as defined of part of the Allocation Model. However, in our example we set the percentage of guaranteed memory to 100% which results in a reservation and a limit of both 512MB.
For the sake of completeness we have changed the guaranteed resources for memory to 50%. Of course the resource pool has changed accordingly. As shown in the screenshot below the reservation on memory has changed to 5120, which “happens” to be 50% of 10240.
This will in its turn also has set the per VM level memory reservation to 50% of the provisioned memory. In the screenshot below the VM was provisioned with 512MB of which 256MB has been reserved.
Summary
As shown in the example the percentage of guaranteed resources will have its impact on the implementation of the resource pool and the limits and reservations associated with these. It is recommended to align the maximum number of VMs with the specified amount of GHz and GB. When limiting the amount of VMs an extreme level of over commitment within the Org vDC can be avoided.
Pay-As-You-Go
This is the model many of you are familiar with and many also adopted in their company, pay-as-you-go. This model allows you to specify the amount of guaranteed resources per VM. When the percentage of guaranteed resources is set to 100% a reservation is set to 100% of what has been allocated that particular VM. Where this model differentiates itself from any of the other models is that it allows you to limit the vCPU speed. By default the vCPU speed is set to 0.26GHz, the impact of this vCPU speed will be shown in example below but be noted that this vCPU speed is set on the VM as a hard limit.
Characteristics
- Percentage of resources guaranteed on a per VM level
- A reservation will be set on a VM level
- By default the VM reservation on CPU is 0% and memory 100%
- By default the vCPU speed is set to 0.26GHz, which means you vCPU will be limited to 0.26GHz
- The Org vDC resource pool is just an accumulation of all reservations set on a per VM level
These characteristics are more in detail explained in the following example.
Pay-As-You-Go example
In the example below the customer requests an Org vDC based on the Pay-As-You-Go Org allocation model with a vCPU speed of 0.26GHz of which 25% is guaranteed. Memory will be left to the default setting which is a 100% guarantee.
Note that the default for CPU is a 0% Guarantee which I changed to 25% on CPU to see the impact. Also note that the vCPU Speed is set by default to 0.26GHz. This is something that you will want to increase! When the Org vDC is created it results in a resource pool with the following characteristics.
As described in the characteristics when vApps are created the associated reservations will be accumulated into the resource pool. When a vApp is created with two VMs (each having a single vCPU and 512MB of memory) this will result in the following changes, note that both the reservation on memory and CPU have changed.
As can be seen on a Resource Pool level a reservation is set of 130MHz which is 25% of 2 x 0.26GHz. A guarantee of 100% was set on memory which translates to 1221MB in total. (Note that a resource pool includes the Memory Overhead of virtualization. See the Resource Management Guide for more details)
As stated the resource pool is jut an accumulation of all VMs. The following is what has been set on a per VM level, first screenshot shows the CPU details and the second shows the Memory details:
As can be seen a reservation has been set of 65MHz and a limit of 260MHz on CPU. For memory a 512MB reservation and limit has been set. If the “guarantee” on memory is set to 50% than the reservation of memory on this VM would be 256MB.
Summary
The tenant will have guaranteed resources per VM. As shown the vCPU speed defined is the limiting factor for a VM. For user experience it is recommended to select at least 1GHz as the vCPU speed. The resource pool created as part of the Org vDC only accumulates reserved resources and does not limit the VMs. Limits are placed on a per VM level. Please note that if the “guarantee” is set to 100% a reservation equal to the limit is set. In the case of a 1GHz reservation this can lead to very conservative consolidation ratios.
Reservation Pool
The third and final Allocation Model is the Reservation Pool. In this model all resources are guaranteed by default. It could be compared to an allocation pool with all guarantees set to 100% and is fairly straight forward.
Characteristics
- Fully guaranteed pool of resources
- A reservation will be set to guarantee resources on a resource pool level
- No reservations or limits set on a per VM level for CPU
These characteristics are more in detail explained in the following example.
Reservation Pool example
In the example below the customer requested 10GHz of CPU resources. As stated, the default guarantee is 100%. As can be seen in the screenshot there is no way to dictate the amount of MHz per vCPU or a Guarantee for that matter.
As expected that results in a resource pool with a limit equal to the reservation as shown in below screenshot.
On a per VM level no reservations or limits are set. This is shown in the following two screenshots.
Summary
As shown the Reservation Pool allocation model is fairly straight forward. A limit equal to the reservation is set on a resource pool level which gives the tenant a guaranteed pool of resources. There are no limits or reservations set on a per VM level which gives the tenant a lot of flexibility. However, this flexibility could lead to severe over commitment within the Org vDC. As such it is recommended to limit the amount of VMs to avoid a degraded user experience.
Conclusion
Each of the three allocation models has its own unique characteristics to fit your customers needs. Is your customer looking for a pool of resources of which a chunk is guaranteed so that they can burst while having a fixed price per month and only pay for the burst space when they are using it? Allocation Pool would be the right answer! Do they have very transient workloads and do they only want to pay for these when using it? Pay-as-you-go would be the best fit. Is your customer just looking to expand their Datacenter with a “dedicated” chunk of resources? Reservation Pool does just that.
However, think before you decide which Allocation Model you will use, think about the amount of resources guaranteed and make sure the amount of resources add up with the max amount of VMs that can be deployed in the Org vDC. One of the most important thing when you are selling a service is user experience!
After I wrote all of this one of my colleagues(Thanks Andy!) was so kind to transform it into a table. This says it all in just two simple tables. The first table describes the characteristics on a Resource Pool level and the second on a Virtual Machine level. Enjoy:
Carl Skow says
Really fantastic write up as usual. I’m finding that my company won’t support a pay-as-you-go chargeback model at this time so I took a lot of interest in your Reservation/Allocation distinction.
Sharninder says
That is an awesome article. We’re trying out vCD in our organisation too and this post really helped me clear some of my concepts 🙂 The product documentation can only take us so far…
Janakan says
Is there a way to reduce the memory allocation % in Pay as you go model below 20%?
Irfan says
I am trying to get an idea of which vCD allocation model people are actually using in the field. Do we have any survey data for this?
Irfan
Duncan Epping says
allocation pool at the SPs, for the enterprise customers I will need to ask around.
IVAN says
here’s a question for you : If you give the vApp user role to a user in a organization. The user can change the type of organization vdc for the vApp he has access… Can we restrict the organization vdc change on vApp for a user ?
Chakrit says
Thank you Duncan! The explaination is great with examples! Andy’s table is somewhat confusing.
Mihai says
Great article, thanks.
Question: is it true that only in the Pay-as-you-go model it is possible to set a custom speed vCPU cores for VM’s ?
I’ve tried that with Allocation Pool and at VM level vCD always forces the vCPU speed to 1GHz.
Thanks!
Duncan Epping says
Pay as you go is the only model that allows that.
home services says
As a designer i just wanted to point out that you have a very nice website , I enjoy the style and design, it really looks great.
ravi says
We shall be using the Allocation and Pay as you Go model. The base Pack of Private (Managed & Un Managed) cloud will be in Allocation Model and any incremental addition will be in Pay as you Go model and how to fix the incremental charging option on allocation model.
How to test the billing generation based on Trend Opportunity and other scenarios.
ramesh says
I’m using chargeback for billing in vcloud.
For a “Allocation Pool” based Organization vDC, if we change CPU and Memory Allocation during mid-month, our full month billing is calculated on the changed values, not prorated . Is this normal ?
e.g. lets say we have Allocated 10GB Momory and 10Ghz CPU to an Organization vDC running on Allocation Model. We change the allocation to 5GB and 5GHz on 15th day. When I generate the bill end of the month, billing is generated on 5Ghz and 5GB for whole month. Ideally, it should prorate the billing as 10GB and 10Ghz for first 15days, and 5GB & 5Ghz for rest of the 15 days.
IF i run a Usage Report, I can see the report correctly shows the change i.e. first 15 days as 10Ghz and 10 Gb, and next 15 days as 5Ghz and 5GB.
Any solution?
Thanks
Charles Llewellyn says
Duncan, great article thanks, however I just want to clarify a something. You state:
“When limiting the amount of VMs an extreme level of over commitment within the Org vDC can be avoided.”
However under the allocation model I do not believe it is possible to over commit resources at the vOrg level as the same ratio is set to both VM and resource pool meaning no over allocation is possible and scales lineally.
I would be interested to hear your response and understand if this is what VMware actually intended as it doesn’t seem to provide any benefit user regarding over commitment to the user as the docs suggest?
“Lowering the guarantee of resources allows for more vApps to fit into the pre-allocation, but this may impact the ability for the vApp to get the resources it asks for.”
Ref: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1026290
Joe Keegan says
Hi Duncan,
I’ve referred to the table at the bottom of this post for quite a while, but today I noticed that the table for the virtual machine configuration maybe incorrect.
The table shows that a virtual machine in an “Allocation” Allocation Model (that has always driven me nuts!) has a CPU limit equaling it’s allocation and a CPU reservation equaling “% of allocation”. But from the text of the post (and from what I have seen) that is not correct. No CPU limit or reservation is set on the VM.
Likewise my understand is that the memory limit equals the amount of memory configured for the VM and it is not equal to the allocation.
I’m assuming these were just copied from the Resource Pool chart and missed when updating the info for the VMs.
Can you confirm I am correct in this observation or if I am misreading or not understanding something.
Love your site and thanks!
Duncan Epping says
I haven’t tested it with the latest version so not sure if this still counts or not. I might do an overhaul at some point, but I don’t have the original tables any longer.
With regards to “allocated memory” what they mean in this table is the “VCD allocated” version which is provisioned memory for the VM.
For CPU I think you are correct indeed, but again I cannot validate it right now.
peterm says
I just read your blog post about vCCM.
I have some questions about that: if I have a vCloud Director installatioan running, how can I offer my organizations to see or generate chargeback reports by themselves?
And can vCCM be used to meter for PaaS and SaaS in VMware environment? Or is it limited to just VM metering (CPU, RAM, storage, traffic)?
For example if I am hosting zimbra, how can I meter for seperate users? Or will I have to install a seperate VM for each customer to meter his specific ressource usage?
Dick Wadd says
seriously this still does not make sense.
Reservation pool is straight forward .. What you pay for is what you get !
I pay for 10GB RAM and 10GHZ CPU ..it’s what I will get garunteed.
What is pay as you go ?
What is allocation pool ?
You haven’t made it simple to understand .. You just presented some facts and some examples ..c’mon make it simple dude!
What is the difference between it and the allocation pool ?
Laymans terms please … All these figures are so damn confusing !
Duncan Epping says
“You just presented some facts” -> not really the most friendly way to start a comment where you are demanding answers…
Dick Wadd says
And what the hell does UNLIMITED mean exactly ?
If UNLIMITED is set does that mean the vm or or resource pool can steal all resources from the parent cluster or pool ?
DEFINE IT …
Unravel the mystery …
Dick Wadd says
So in an allocation pool I get guaranteed resource and have a limit ?
What’s the ‘ burstability’ resource between guarantee and limit … Do other tenants contend for this area of resource ? Who pays for that ?
Ok cloud provider I have 100$ so you gonna give me a reservation of 50% and a limit of 75% ? And i can create 100 VM’s
What does that even mean ?
Define it please … !
Parag says
Thanks for the wonderful series of articles on vCloud. I had a question about allocation models.
Can we change the allocation model of an Org VDC after creating it ? I am asking because I am working on a product which sits on top of vCloud. I would like to automatically create an organization VDC using the API when an organization is created. However, I do not know beforehand, which allocation model they might want to use. Is it possible to create a default Org VDC with PAYG, and then allow the organizational admin to change the allocation model ?
Thanks.
Thejas K V says
Great post…
mrambig says
namaste duncan, i am sure you meant “10,000MHz” and not “10.000MHz”, please correct the period to comma, i was so confused at first. Thank you for the short, precise, concise article.
Duncan Epping says
Well that depends on where you live right… some countries us a dot, others use a comma 🙂
Strobber says
Great article, Dunkan! Thanks