Page History

...

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

...

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.

...