vSphere 7 - DRS Scalable Shares

In my previous blog I showed some cool new features within vSphere 7 DRS and ended with an example of what Sharable Shares does. Now I will show you how the shares are calculated and how I tested this feature.

Scalable Shares

Scalable Shares are not enabled by default, but when enabled they allow to have dynamic and relative entitlements within resource pools. If you have used resource pools before, you might know that assigning a VM to a resource pool with high shares configured isn’t a guarantee that the VM receives more CPU cycles than a VM in a resource pool with low shares configured. Scalable Shares solves this. But remember that methods like this only work when resources are scarce. When there is resource contention.

Let me explain with an example that I build in our LAB. I created a resource pool with a limit of 8 Ghz CPU cycles. Within that resource pool I created two resource pools; Production and Test. The Production resource pool has high shares (8000) and the Test resource pool has normal shares (4000) configured. In total there are 12000 shares to be divided, meaning 5,333 Ghz for Production and 2,667 Ghz for Test. So far so good.

Resource calculation with normal DRS Shares

Now for some reason there are more VM’s in the Production resource pool then there are in Test. Even though the VM's in the Production resource pool also have a high Shares value they end up receiving less CPU cycles then a normal shares VM in the Test resource pool. Have a look at the following pictures:

As you can see the 3 Production VM’s each get 33% of the 5,333 Ghz assigned to the Production resource pool. So, in a worst-case scenario the VM would receive about 1,78 Ghz of CPU cycles. This number can be viewed under the monitoring Tab of a VM.

Now the Test VM is alone and receives 100% of the 2,667 GHZ.

As shown in the pictures above the total 8 Ghz of CPU cycles are divided as followed:

Resource calculation with Sharable Shares

Sharable Shares isn’t enabled by default but can be enabled on a vSphere Cluster or on Resource Pool level. When enabled on the Cluster level it is enabled for all resource pools within that cluster.

After a view seconds, a minute at most, the new calculation method is active within the cluster.

The new calculation method is described as followed:
Resource Pool Shares = (4 vCPU * Shares of Pool) * (Total number of shares of all vCPUs in resource pool)

With the following facts:

• A resource pool looks like a VM with 4 vCPUs and 16GB of memory to DRS
• Scalable Shares looks at the total amount of shares in the Resource Pool (all vCPUs!)
• For a resource pool: high is 8000 shares, normal is 4000 shares and low is 2000 shares
• Note that this is based on 4 vCPUs, so the real values are 2000, 1000, 500

In practice this means that the total number of shares is calculated based on the number of VM is the total pool. Each VM gets a portion based on the number of its own and the resource pool shares.

So how does this work for our example?

We have 3 VM’s, each with high CPU shares (2000), in a Production resource pool with high shares (8000 = 4 vCPU). 3 * 2000 * 2000 (1 vCPU) = 12000000 shares. The test VM has normal CPU shares 1000, in a resource pool with normal shares (4000 = 4 vCPU). 1 * 1000 * 1000(1 vCPU) = 1000000 shares. The total number of shares in our example = 13000000 shares.

A VM in our Production resource pool will receive 4000000 shares out of the total 13000000 shares where the VM in the Test resource pool will receive only 1000000 shares. Which make the assignment of the resources more logical and predictable.

We can also see this by looking at our ‘Worst Case Allocation’ again.

8 Ghz divided by 13000000 shares times 4000000 shares for our production VM is 2.46 Ghz.

And the VM in the Test resource pool now only receives 0,6 Ghz, a quarter of what the production VM’s receive in a worst-case scenario. 8 Ghz divided by 13000000 shares times 1000000 shares = 0,61538 Ghz.

As shown in the pictures above the total 8 Ghz of CPU cycles are divided as followed:

Again, bear in mind that mechanisms like Scalable Shares only start to work when there is more demand than resources. That’s why I found the best place to test and check the scalable shares using the ‘Worst Case Allocation’ number.

Hopefully you enjoyed this blog and if you would like to read more about VMware product check our other blog posts or read some of the blogs that got me interested in the new improvements of vSphere 7 DRS.