Shares seem to be a topic that comes up a lot just because not everyone understands them very well. So I wanted to take a moment to see if I can take a stab at explaining them. I know there are several good explanation that exist already, but it never hurts to have something explained in a slightly different way.

The first thing to note is that…. Unless there is resource contention, Shares do not matter!  Shares only play a part, and come into play, when there is contention for resources. It is entirely possible you might be in an environment where you have so many resources that you don’t need to think about Shares. If that is the case, Great. However, it never hurts to think about how you would setup your shares, or to even set them up on the disastrous possibility that your resources fill up overnight(which is probably unlikely).

BASIC SHARE THEORY

There are 3 default settings you can choose for shares. They are High, Medium, and Low, and they correspond to a ratio of 4:2:1 respectively. Let’s take a closer look at this by using an example

We have 3 vms that each have the same amount of CPU and Memory assigned to them. The names of vms are vm-green, vm-yellow, vm-red(Can you see where I am going with this yet 🙂 ).

I assign vm-green the High(4) share setting.
I assign vm-yellow the Medium(2) share setting.
I assign vm-red the Low(1) share setting.

Now our environment becomes strained for resources, which means the shares take affect. To help understand what happens, let imagine each of the shares is represented by a ball which has the color with the name of the vm it represents. In case that in it of itself is a poor explanation

vm-green’s shares will be 4 green balls
vm-yellow will be 2 yellow balls
vm-red will be 1 red balls

I want to note again that the numbers were chosen because of their individual share settings High(4):Medium(2):Low(1).  Since their is resource contention and all of the VMs are turned on, let’s throw all their balls into 1 hat.

When a resource becomes available for use a draw is made from the hat to see who the resource will go to.  With vm-green having the most(4) balls in the hat, it is obvious he is most likely to recieve the resource, but what is the exact number?

There are 7 total balls in the hat, and vm-green has 4 of those, so vm-green has a 4÷7(4dividedby7)= 57% chance to get the resource. Makes sense…. right?  For the sake of completion

vm-green will have a 4÷7(4dividedby7)= 57%
vm-yellow will have a 2÷7(4dividedby7)= 28%
vm-red will have a 1÷7(4dividedby7)= 14%
(Yes, it doesn’t add up to 100 because I didn’t include the decimals…)

After a period of time when resources are in contention, those VMs will also occupy the percentage of shares listed above. To say it another way, if vm-red is getting 14% percent of the resources that come available, eventually it will occupy 14% of the total resources available to those VMs.

If, for some reason, we turn vm-red off, it then it no longer taken into account in the share calculation and resource distribution(because it is now turned off).  In that case the total number of shares becomes 6, from adding the shares of the remaining VMs together. In this scenario…

vm-green will have a 4÷6(4dividedby7)= 66%
vm-yellow will have a 2÷6(4dividedby7)= 33%
Math is fun right!?!?!

Now all this is great for when the VMs all have the same amount of CPU and Memory allocated to them, but what happens when they don’t?

USING CPU SHARE VALUES

Pulling from page 9 of VMware’s Resource Management Guide, these number must be taken into account…

For a quick example of how this works, the same two VMs are powered on: vm-green, vm-yellow

vm-green has 2 CPUs
vm-yellow has 4 CPUs

vm-green gets 2(CPU)·2000(Shares per CPU)=4000 shares
vm-yellow gets  4(CPU)·1000(Shares per CPU)=4000 shares

Looking at it like this, each of these to VMs get an equal chance of gaining CPU resources as they become available because they each have the same amount of shares. It is important to understand, because in this specific scenario, even though vm-green has been given a High share setting, it will have an equal chance for CPU resource. Plan accordingly in your own environment.

Similar calculations can be done for Memory Shares.
CUSTOM SHARES

Although it is generally recommended to NOT use custom shares, I will touch on it just briefly.

Essentially when using custom shares the best  advice I can give is to be careful and be aware.

If  vm-conrad has a CPU custom share value  of 8000 associated with it, that ends up being 8000 shares per CPU!!! If I then move that vm to the same pool as vm-green and vm-yellow, that is obviously going to drastically affect what vm-green and vm-yellow are entitled to when resources become available.


0 Comments

Leave a Reply