Page History

...

When the cluster overprovisioing factor = x and vms are deployed then

• Total Capacity = (actualHardwareCapacity * x)
• Used Capacity = sum (service offering of each running vm) + sum (service offering of each stopped vm 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 existing 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.

...

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 => (1GHZ(.5 GHZ/1)*2 + (.5 GHZ/1)*2 => 2GHz
The reason is want to guarantee minimum cpu in (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 .
So the reason we 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 on the hostfor 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 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. 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

...