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. The overcommit ratios will be stored in the cluster details table. 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

...

There will be no changes to the db. We will add the cpu and ram overcommit ratios in the cluster_details table.

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

...

2b. or accept the change but not add more VMs anymore ( preferred method)

if we decrease the factor - currently we allow doing that (say change from 2X to 1X) . Lets say If the allocation is beyond the factor already (say 1.5 X) then what it means is no future allocation will be allowed and secondly the dashboard would start showing >100% allocated which might confuse the admin (in our example it would show 150%).  The admin would also start getting alerts for capacity being already exhausted. i.e. we should accept the new value and allocate only if the system has enough capacity to deploy more VMs based on the new overcommit ratios.

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.

What should be the behavior when changing a cluster setting form no overcommit (overcommit ratios are one ) to some overcommit value.

1.) Check if all the hosts in the cluster have the overcommit capability. If any one of the host is not capable, the cluster's overcommit ratios will remain 1 ie no overcommit.

2.) Mark a cluster for overcommit while creating. Every host that is added to the marked cluster will be checked for the overcommit capability. The hosts in the unmarked clusters will not be checked and will not be allowed to use the overcommit feature.

3.) Check all the hosts for overcommit capabilities by default.

Task Breakup

Discussions with community 3 days.
updating functional spec 1 days.
Coding 4 days.
testing 2 days.