vCloud Resource Management – Allocation Pool Without Elastic vDC


Many service providers have been deploying their services using vCloud Director of the past couple years.  Of the various models I have seen the Allocation Pool used most often, but there is two ways it can be configured and each way changes the way your virtual machine resources are handled.  With vCloud Director 5.1 you have the option of enabling Elastic vDC which allows you to span clusters of vSphere hosts.  It’s very useful, however it manages the virtual machine’s resource differently than when it is not enabled.

Since I returned from the networking world to the vCloud world I decided to get back into the lab and see first hand how it works myself.  Last year Frank Denneman and I co-authored a paper on the vCloud Allocation Models however it was based on vCloud 1.5 and the Allocation Pool now has this new option.  I will break this topic up into a few posts.  One covering the Allocation Pool offering without Elastic vDC enabled, another with it enabled, and finally the Reservation Pool and some of the advantages it has.  Why do I feel this important?  The more you know about how vCloud Director and vSphere is managing the resources the better you will be able to design your use of the service and maximize the number of workloads you want to run.  vSphere resource management itself has not changed much, but these changes to the vCloud Allocation models has allowed varying levels of control.  Knowing how it works may be important to some folks who want to understand and maximize just how many virtual machines they can run in any given provider offering using the Allocation Pool model.

What You Get

Many providers list simply the following specifications around their offerings and in various sizes:

  • 5Ghz burstable up to 10Ghz
  • 20GB vRam
  • “X” Amount of storage
  • “X” Amount of bandwidth
  • “X” number of public IP’s

What I am going to do is attempt to break down only the compute and memory component of this example without Elastic vDC enabled and then again with it enabled.  I feel people can better understand how your virtual machines will be deployed in this offering leading to better consumption of the offering.   For the vCloud Director savvy this may seem like review, but for the new people to this it’s about education.  You may not know if your provider has elastic enabled or not, so understanding both examples may empower you to just ask them.

Example vCloud Allocation Pool Settings

In order to understand further we need to break down the numbers above to what is configured in vCloud Director and thus what is translated to vSphere itself.  This is because vSphere is actually what is doing the resource management in most cases.  vCloud Director is just giving the setting inputs.  Below is a basic translation, and we have to remember with this model some settings are applied both to a resource pool and the virtual machines.  We will cover that later on, but remember this example is WITHOUT elastic vDC enabled.

What The vRAM Resources of 20GB Means

  • 20GB Memory Allocation in vCloud Director
  • 100% Memory Resources Guaranteed in vCloud Director

vCloud Air_vCD_memory

This in turn translates to vSphere as a resource pool with a 20GB limit, and a 20GB Reservation.

vCloud Air_vSphere_memory

What The vCPU Resources of 5Ghz with 10Ghz Burstable Means

  • 10Ghz CPU Allocation in vCloud Director
  • 50% CPU Resources guaranteed in vCloud Director

vCloud Air_vCD_CPU

This in turn translates to vSphere as a resource pool with a 10Ghz limit, and a 5GHz Reservation.

vCloud Air_vSphere_CPU

Understanding the Resource Pool Created

As you can see so far what gets created with these settings is a single vSphere Resource Pool with a full 20GB of memory reserved for you, along with a limit, or cap, as well.  The initial 5GHz of CPU is reserved and there is a 10GHz limit you can “burst” into, but not over.  Simply put is that all your memory is reserved, and half your CPU is also reserved but you can leverage additional CPU resources of the cluster pool with other tenants.  In both cases you can not go over the limts that have been set.  So how do these affect virtual machine deployments?  Let’s examine the settings of a virtual machine deployed to this model and settings.

The Individual Virtual Machine Settings

The example virtual machine deployed will be your basic 2 vCPU by 2GB variety as that’s pretty common for most people.  The thing we need to completely understand from the previous settings is that in the Allocation Pool Model, the percent reservation listed for memory not only applies to the vSphere resource pool, it ALSO applies to the virtual machines deployed.

Once a virtual machine is deployed looking at the vSphere side of things we can see that the following CPU settings are applied.

vCloud Air_VM_CPU

What is tells us is nothing really impactful.  The individual virtual machine has no specific machine level CPU reservation or limit.   Therefore it can leverage what is available in the overall pool of 5GHz and the “burst” space.  The memory settings are a little bit different.

vCloud Air_VM_memory

Here we can see that a 2GB reservation has been applied to the virtual machine.  If you recall the vCloud Allocation Pool is set to 100% memory reservation and this Virtual Machine was configured for 2GB.  If we shut it down and changed the memory we’d also see this reservation change to match the new settings.  It’s also something to point out that without elastic vDC enabled there is nothing specific set for the CPU other that the resource pool level having the initial 5GHz reserved.  Each virtual machine will use that reserved and can go up to the full 10GHz.

Why Is This Important?

Well I am not going to go into the full depth on this as Frank and Duncan have done that plenty over the years.  The good news is the fundamental usage of these settings has not changed.  What I will also not get into is the topic of overhead reservations or HA admission Control at this point.  If you want to know more about that you can read Frank and Duncan’s books on the topic or the vSphere Resource Management Guide.  However, it is useful to learn about these topics at some point.

The purpose here is to let you see how much you can carve up a Virtual Private Cloud based on your virtual machine configuration with very “rough” calculations.  What we know about Resource Pools and Per Virtual Machine reservations when they are combined is that the individual machine reservation of 2GB is removed from the overall pool of 20GB leaving 18GB left for more virtual machines. You can see as we add more machines, the 20GB pool will have those machines reservations removed from it as well until there is no more water left in the pool.

Simply put as you can roughly determine in a single Allocation Pool  instance out of the box you can get any number of virtual machines based on the sizing of the machine themselves.  The basic math for a ballpark as you can see is certainly not rocket science.

  • 2GB Machines is less than or equal to 10
  • 1GB Machines is less than or equal to 20

If you mixed and matched you’d be somewhere in between of course, and you can add-on more resources as you need to scale to more machines.  I should say this is not meant to be a sizing guide, this is for education purposes only so you can see what you can run in your VPC.  Stay tuned for the Dedicated Cloud breakdown which is actually pretty interesting.

If you have never really played with reservations and limits I have been saying for over a year as a vCloud Director advocate and architect, you should start understanding them if you want to understand the “why” of how things work.  I realize many vSphere customers have not deployed reservations on resource pools or even adjusted the per virtual machine settings in-house.  However, since vCloud Director does it for you it’s maybe worth knowing a little more so you can design applications to maximize the various options.

Much of this changes when you simply enable Elastic vDC so I will cover that in the next post.  Please leave comments and questions below so the conversation can be useful to others.


About Chris Colotti

Chris is active on the VMUG and event speaking circuit and is available for many events if you want to reach out and ask. Previously to this he spent close to a decade working for VMware as a Principal Architect. Previous to his nine plus years at VMware, Chris was a System Administrator that evolved his career into a data center architect. Chris spends a lot of time mentoring co-workers and friends on the benefits of personal growth and professional development. Chris is also amongst the first VMware Certified Design Experts (VCDX#37), and author of multiple white papers. In his spare time he helps his wife Julie run her promotional products as the accountant, book keeper, and IT Support. Chris also believes in both a healthy body and healthy mind, and has become heavily involved with fitness as a Diamond Team Beachbody Coach using P90X and other Beachbody Programs. Although Technology is his day job, Chris is passionate about fitness after losing 60 pounds himself in the last few years.


  1. Hi Chris,
    Thanks for this article. One more thing that it is not very clear on each articles about Allocation model (with vcd 5.1.2) and the impact of the vCPU Speed that we can set on the Allocation model (not for PayAsGo model which is very clear at vSphere level). I think there is no impact at vSphere level in resource CPU allocation, but only on the way that vcd is calculating the utilisation of CPU on the orgVDC. Is it that ? If yes what is the best way to implement a consolidation ratio for exemple : 4vCPU/CPU on the org vCD that for exemple is expected by a consumer. Do we have to change the vCPU speed for exemple from 1 to 0.25 Ghtz or increase the orgVCD CPU capacity to 4*CPU capacity ?
    Thanks for sharing an exemple if you have it.

    • Thanks for the note. I just enabled Elastic vDC (Which is the only way the vCPU speed setting is exposed in the UI, and the next post will run through the sample in the same way so you can compare the differences. Just need a day or so to put it together. If it does not cover your questions then, we can use the discussion to dig deeper.

  2. Thanks, always interesting and thought provoking article. I have blogged about similar thing at and I’m glad I’m with you on it. In fact I have come up with excel sheet which can help do the mix and match here -> . However I was unaware that CPU speed gets exposed by enabling elastic cloud. Looking forward to next one.

Leave a Reply

Your email address will not be published. Required fields are marked *