Page History

...

• We 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.
• vm_details will be populated with the cpu over provisioning and memory over provisioning factors(only for vmware) from global setting. For other HVs memory over provisioning will be set as 1.

Caveats

...

What should the behavior be if admin changes the overcommit factor for a cluster that conflicts with the current situation. For example,lets assume Cluster X has an over commit factor of 1.5x for memory and the admin wants to change this to 1x - i.e no overcommit (or changes from 2x to 1.5x) - however, based on the "older" factor, CS might already have assigned more VMs - when the admin reduces the overcommit value  

1. if there is no conflict, there is no issue

...

• 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.