Page History

...

Cloudstack will deploy the vms based the overcommit ratios. If the overcommit ratio of a particular cluster is updated, only the vms deployed hereafter will be deployed based on the updated overcommit ratios, this is ensured by storing overcommit ratio with which the vm got deployed stored in user_vm_details. The overcommit ratios for cluster will be stored in the cluster details table and will be inherited from global setting at the time of creation. Also whenever we add a host we will check of the host has the capabilities to perform the cpu and ram overcommiting. These capabilities will be stored in the db.

...

Supported Hypervisors.

XenServer
KVM
VMware

Capacity calculations on MS.

Capacity calculation model will be changed to align with the hypervisors calculation. When a vm is deployed with "x" overprovisioing factor we want to guarantee (service offering of vm / x ) during its lifecycle even though the over provisioning changes.

...

Reserve memory = don’t reserve

Same model is followed for cpu.

KVM

TBDThe overcommit ratios are dynamically plugged into the capacity calculations. All the capacity calculations is done based on the overcommitted value of capacities. So if the overcommit ratios is decreased the used capacity may go beyond 100%. 
Example:
Overcommit =2 
capacity = 2GB
capacity after overcommit = 4GB.
Now if we deploy 3 VM of 1 GB each  used =3GB
free = 1GB
used % = 3/4 *100 = 75%
if the overcommit ratio is decreased to 1
used = 3GB
free = -1GB
used % = 3/2 *100 =150% (will generate alerts based on this.)

DB changes:

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.

...

But, say the allocation done till now is still within the new factor (say 0.8X is allocated currently) then allocation would still be allowed and dashboard would show 80% allocated so in this case everything seems to be correct and we should allow admin changing the factor.

Check if host has capabilities of overcommiting.

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.

...

Note :- The overcommit ratios are dynamically plugged into the capacity calculations. All the capacity calculations is done based on the overcommitted value of capacities. So if the overcommit ratios is decreased the used capacity may go beyond 100%. 
Example:
Overcommit =2 
capacity = 2GB
capacity after overcommit = 4GB.
Now if we deploy 3 VM of 1 GB each 
used =3GB
free = 1GB
used % = 3/4 *100 = 75%
if the overcommit ratio is decreased to 1
used = 3GB
free = -1GB
used % = 3/2 *100 =150% (will generate alerts based on this.)

Alert Generation.

All the alerts are generated based on the global threshold values. Will change this behavior once we have
thresholds have thresholds per cluster.

...

HV prerequisites to use cpu and ram overcommit.

The feature is dependent on the OS type ,Hypervisor capabilities, and some scripts.

...

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

Behavior when overcommit is changed while there are VMs running in the cluster.

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
• In this case all the VMs prior to the overcommit change will continue to run with the same settings. Only the newly deployed VMs will have the new setting based on the new overcommit value.
• On overcommit change we scale the used and reserved capacities based on the new overcommit values. This happens when the capacity checker runs. The time interval between consequent runs can be changed by changing the global parameter capacity.check.period.
• The capacity as seen by the cloudstack will not be correct until the capacity recalculate happens.
• As of now cloudstack dose not check for any perquisites. It is the admin's responsibility to provision accordingly.

Things To do

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