Page History

Introduction

...

This document describes the Cpu/Ram overcommit feature.

...

• Total Capacity = (actualHardwareCapacity * y)
• Wiki MarkupUsed Capacity = \ [sum (service offering of each running vm deployed when factor was x) + sum (service offering of each stopped vm deployed when factor was x in the was x in the skipped.counting.hours)\] * y/x \+ sum + sum (service offering of each running vm deployed when factor was y y ) + sum (service offering of each stopped vm deployed when factor was y in the was y in the skipped.counting.hours)

Ideally you shouldn't change the over-provisioning factor in a cluster with vms running. This is because the some of the vms got deployed with the previous factor x. 
Lets say you still want to change the factor. On changing it, both used and total capacity are multiplied by this factor to keep a track of available capacity.

Let's understand the capacity calculation below through an example :-

Cluster – c, 
cpu over provisioning = 1, 
Total cpu = 2GHZ

when we deploy 2VMs of 512Mhz service offering each then 
totalCapacity = 2GHz 
AvailableCapacity = 1GHz
UsedCapacity = 1GHZ

Now change the cpu over provisioning ratio of cluster c to 2
totalCapacity = 4GHz 
AvailableCapacity = 2GHz
UsedCapacity = 2GHZ

Notice the difference in multiplication here. Both used and total capacity are multiplied by this factor. Used Capacity in the new model after changing the factor = (service offering of vm / overcommit it got deployed with) * new overcommit => (.5 GHZ/1)*2 + (.5 GHZ/1)*2 => 2GHz
The reason is want to guarantee (service offering of vm / overcommit it got deployed with) in case of contention. So when a vm is deployed with "x" overprovisioing factor we want to gurantee (service offering of vm / x ) during its lifecycle even though the overprovisioning of cluster is changed. So these vms will get .5Ghz each during contention and therefore available is still 1 Ghz during contention.
The reason to scale the used cpu is to keep track of the "actual" amount of cpu left for further vm allocation. Keep the focus on available capacity. So now available capacity is 2 Ghz when over-provisioning = 2.

Now if we launch 2 VMs with 1Ghz cpu service offering
totalCapacity = 4GHz 
AvailableCapacity = 0GHz
UsedCapacity = 4GHZ 
Calculation for used capacity for 4vms ((service offering of vm / overcommit it got deployed with) * new overcommit) = 
(512Mhz/1)*2 + (512Mhz/1)*2 + (1Ghz/2)*2 + (1Ghz/2)*2 = 4Ghz

In case of contention first 2 vms (512Mhz service offering) get 512Mhz/1 => .5Ghz each and the next 2 vms (1 Ghz service offering and 2 overprovisioning) also get  (1Ghz/2) = .5Ghz each. So adding up means 2Ghz which is the actual capacity of the host and so there is no more capacity left to accomodate more vms.

now suppose we change the over provisioning to 3 
totalCapacity = 6 GHz 
AvailableCapacity = 0 GHz
UsedCapacity = 6 GHZ
Calculation for used capacity for 4vms ((service offering of vm / overcommit it got deployed with) * new overcommit) = 
(512Mhz/1)*3 +(512Mhz/1)*3 +(1Ghz/2)*3 + (1Ghz/2)*3 = 6Ghz

Now this is assuming, you haven't stopped and started the vms all this while. Say now you stop and start 1 VM with 512Mhz and another VM with 1Ghz. The over-provisioning factor ratio changes for these vms to 3 each. Note the denominator in the calculation. 
totalCapacity = 6 GHz 
AvailableCapacity = 1.5 GHz
UsedCapacity = 4.5 GHZ
Calculation for used capacity for 4vms ((service offering of vm / overcommit it got deployed with) * new overcommit) = 
(512Mhz/3)*3 +(512Mhz/1)*3 +(1Ghz/3)*3 + (1Ghz/2)*3 = 4.5 Ghz

All this is done to track the available capacity for further vm allocation. If you track the "actual" capacity left on host = .5Ghz (out of 2Ghz). So now you can still create a vm with 1.5 GHz and cluster over-provisioning = 3 and hypervisor will guarantee 1.5/3 = .5 Ghz during contention.

The upside of new model is we are guaranteeing QOS as (service offering of vm / x ) during its lifecycle vs the old model

Hypervisor Calculation

...

Xenserver 

Deploy vm with service offering ‘s’ and memory overcommit factor ‘f’ and overcommit factor ‘c’   --

• Static Min memory = Dynamic Min memory = service offering / factor ==  (s/f)
• Static Max memory= Dynamic Max memory =  service offering == s
• Each vm ensured Min memory during contention. •
• No overprovisioning means min=max 
• Min memory = Max memory= service offering == s
• CPU weight assigned to vm = (service offering / factor) / host hardware speed == (s/c) / actual_host_speed
• CPU Cap = (serviceOfferingSpeed * serviceOfferingCpus) / actual_host_speed 

...

Same model is followed for cpu.

KVM

TBD

DB changes

...

• We Whenever creating a cluster, MS will add the cpu and ram overcommit ratios in the cluster_details table. They will be inherited from global settings for cpu over provisioning and for Vmware from memory over provisioning global setting. For othe HVs memory over provisioning will be set as 1.memory over provisioning. 
• In case its an upgrade, existing global values will be carried over to the cluster_details. Do note that memory overprov existed only for vmware and would be carried over during upgrade only for vmware.
• vm_details will be populated with these factors present at the cluster level when the vm is deployed. 
• In case the cluster factor changes, vms factor in vm_details wont change until you stop/start the vm.
• For upgrade vm_details will be populated with the cpu over provisioning and memory over provisioning factors(memory only for vmware) from global setting. For other HVs memory over provisioning will be set as 1.

...

kvm dose not support automatic adjustment of the guest OS memory dynamically

Note -

• Almost all the hosts have the capability to overcommit, and it is up to the admin to make sure of it. Even if the host is not configured properly, cloudstack will try to set the parameters assuming it has capability.
• As of now cloudstack dose not check for any perquisites. It is the admin's responsibility to provision accordingly.

Future Tasks

...

• Keep these factors in the service offering.
• Trigger the capacity recalculate when the overcommit is changed. No need to wait until capacity checker runs.
• Create action event on overcommit change.
• Create action event when capacity recalculate is complete.