Why Do I Care About This Topic?
Maybe you don’t, but if you are like some folks I have talked to in the past few months there is some level of confusion on the relationship between Allocation Models in vCloud Director and the vSphere Resource Pools that get created. I have found myself discussing this relationship more and more especially with customers that have not traditionally used vSphere resource pools. In turn understanding this combined with in depth knowledge of how vSphere resource pool settings affect the system could make you better understand how it all fits together. I have found that by relating the two subjects in discussions that people are more in tuned to what is going on inside the HA/DRS cluster hosting the resources and they are in a better position to manage the system.
What are Allocation Models?
There has been a few posts out there I would like to start by referrencing if you have not seen them that explain what the Allocation models in vCloud Director are and some of the impacts as listed below.
- Allocation Models for Organizations using vCloud Director
- Did you know? vCloud Director Reservation Pool allocation model fact
- vCloud Allocation Models – YellowBricks (Written before mine but same topic)
The first touches on the definition of these models and the second is a short blog by my friend and colleuge about the shares you can also set. The last one is a very similar post by Yellow-Bricks written before mine, and I admit I never saw or read it before I wrote up mine. Something I always find myself explaining to customers is how each model is translated to vCenter either as a resource pool OR directly on the Virtual Machines themselves with either a reservation, limit or neither. We often here customers using vSphere say they do not use resource pools for various reasons which I will not go into. However when you use vCloud Director EVERYTHING is translated to a resource pool as you can see below.
In turn you also have certain resource constraints added to those pools or onto the Virtual Machines based on the Allocation Model. This also affects the possiby billing and chargeback calculations becuase vCenter Chargeback is also tied to these allocation models. Let’s take a look first at the allocation model and then show how the settings chosen for the model translate to the vCenter Resource settings. From there some things may come to light, not the least of which will be your almost instant need to purchase and read the latest DRS/HA book that was written. Why? Because you will start to ask yourself how does all of this affect my HA admission controls and DRS based on everything going on. I like to start with the two polar opposite models and then discuss the one that meets in the middle. This is a great example of why having your own vCloud in a Box lab is just so important.
Pay As You Go Model
As we see in the KB article this sounds pretty self explanatory, after all you “Pay as you Go” right? Well this may have a few impacts on your design decisions when you think about that. First off, it is the MOST unpredictable for billing purposes. You’re consumers will not really be able to budget because they will be charged either higher or lower based on the usage and number of Virtual Machines they fire up. Provided they are okay with that let’s look at the settings on an Organization vDC in my lab then look at the vCenter settings.
Here we can see the options based on Pay As You Go where we can actually set some CPU and memory. Now what does this look like in vCenter? As we can see below the resource pool created has essentially nothing set at the Resource Pool Level. However take a look at the individual Virtual Machine in this vDC.
- CPU Limits Assigned per VM in PAYG
This means EVERY Virtual Machine deployed in this Model and vDC will be set individually and will not be allowed to be changed. The only thing that will change is if the user changes the memory assigned to the VM then the limits will update accordingly. This also means that each Virtual Machine will inherit these settings and cannot be changed by the user.
Reservation Pool Model
So the opposite end of the spectrum is setting up a Organization vDC to pre-reserve the resources based on the Organization’s requirements. This from a billing perspective is the most predictable for the consumer because they get a set amount of resources for them to use as they see fit. They pay if they use it or not and they are not sharing their resources with other consumers.
We see able that the options are different and this in turn creates a vCenter Resource Pool with the settings indicated below. Note that everything is set to not expandable or unlimited and the resources are matched to the vCloud configuration.
Here we see that a few simple looking settings in vCloud Director make some significant settings on the Resource Pool. Reservations AND Limits on the pool are set for both CPU and Memory. This makes sense because the consumer has agreed to this “bucket” of resources. You see the numbers match the settings in vCloud Director. These can also be changed by the vCloud admin should the consumer need more resources.
Reservation Pool Model – Cont.
Now let’s peak at a VM running in this vDC and the settings applied on the individual VM’s within this vDC model. What we notice is that here every VM is set as equals with no individual limits or reservations. Effectively the opposite of the Pay As You Go Model. This means every Virtual Machine in this vDC will get equal usage of the total available resources with no one vApp taking more than another. Also we see the user can control the settings on the individual VM in vCloud Director in this model as well should any individual virtual machine need specific reservations or limits over other’s in the vDC. This is where we say “Users can control the individual resources” which is what Duncan was highlighting in the article above.
Allocation Pool Model
So now let’s look at the third option in detail known as the Allocation Pool model. This is similar to the Reservation Pool whereas the settings are applied to the vCenter Resource Pool itself. The difference is the users cannot control the vApp resources only the system administrator can alter those from vCloud Director.
Now again in vCenter here is what the Resource Pool shows which is very much the same as the Reservation Pool settings. The main difference is we not only set the allocations, but we can set a percentage guarantee on this vDC so that not all the resources are pre-allocated. Based on the percentages the actual amounts will vary on the reservations and limits. We also note that like the Reservation Pool there is NO expandable reservation or anything unlimited.
This means only the system administrator can alter the settings of the vDC and all the Virtual Machines within it will in turn look similar to that of the Reservation Pool, but users cannot edit or control them as we see below. What we also see is the per VM settings are a hybrid of the previous two models. The CPU is wide open but the memory gets set to limits and reservations to preserve the memory settings. This is where we see that this model is more of a hybrid of the other two where we set the resource pool and the virtual machine. Frankly this appears to be possibly something incorrect as there is no vCD option to change or set the per VM resource information. I am looking into this further because on the surface it just does not look right to me.
UPDATE: I did look further into the settings for a Virtual Machine under the Allocation Pool Model, and by design the percentage settings on the pool are ALSO passed down to the indivudual VM which is why the memory reservation is set. However, it seems ONLY the memory is set as indicated below NOT the CPU reservation. This explains why each virtual machine has settings specific to them inside the Allocation Pool Model. However, in the UI the only mention of the settings is that they are applied to the Resource Pool, but as I said the percentages are also applied to each Virtual Machine.
Moving vApps Between Allocation Models
You can in fact move any given vApp while powered off to another vDC with a different allocation model. There is a number of use cases where this could be useful. The most common I can see is that you thought your vApp would be fine with Pay As You Go, but over time the vApp becomes more Tier 1 being utilized more and you simply want fixed payments. You simply shutdown your vApp and move it to another vDC with the new allocation model. By default you’re vApp will inherit the settings of that vApp. However what I have found in limited testing is that certain moves require some manual intervention. If you move INTO a Reservation Pool, any PER Virtual Machine settings that were previously on the vApp will remain. I suspect this is because specifically with a Reservation pool the user can control the settings. This means if you want to level the settings back to “Unlimited” with no reservations you need to change it manually before powering on the VM. However moving from PAYG to AP, or out of RP to PAYG or AP the settings seem to adjust automatically. This is most likely because those are system controlled no user controlled like the Reservation Pool model.
Summary
So taking all this into account the reason for all the information is to show at the end of the day all these settings can affect your cluster within vSphere. Certainly read Duncan’s new HA/DRS book, and think about where you might see some interesting things happen in the environment, like a VM not powering on due to HA Admission Control based on the placement and the usage of the resource limits and reservations. For those that have never used vSphere pools in the past and are looking to VMware vCloud DIrector, hold on tight becuase you will start seeing a lot of these things get created.