Page History

...

1) pool.storage.allocated.capacity.disablethreshold: Percentage (as a value between 0 and 1) of allocated storage utilization above which allocators will disable using the pool for low allocated storage available

2) pool.storage.capacity.disablethreshold: Percentage (as a value between 0 and 1) of storage utilization above which allocators will disable using the pool for low storage available

3) VM Allocation Algorithm: 'random', 'firstfit', 'userdispersing', 'userconcentratedpod_random', 'userconcentratedpod_firstfit' : Order in which hosts within a cluster will be considered for VM/volume allocation

4) network.throttling.rate: Default data transfer rate in megabits per second allowed in network.

5) router.template.id

6) Guest Domain Prefix

7) External DNS Usage

8) storage.cleanup.interval

API Changes:

Instead of over loading the present createZone API and updateZone API a new API is introduced say "UpdateZoneLevelParamters API".

During the creation of zone default values for these parameters will be set in the data_center_details table.

These can be updated using the "updateZoneLevelParamters" API. All the parameters are optional so that we can update whatever parameters we want to.

...

API Name

...

API Parameters

...

API response

:

             This needs to split per each hypevisor to be able to provide the values for each hypervisor.

             xenroutertemplateid: ID of the router template incase of xenserver
             kvmroutertemplateid: ID of the router template incase of kvm
             vsphereroutertemplateid: ID of the router template incase of vsphere
             hypervroutertemplateid: ID of the router template incase of hyperv

6) Guest Domain Prefix: Default domain name for vms inside virtualized networks fronted by router

7) External DNS Usage: Bypass internal dns, use external dns1 and dns2

8) storage.cleanup.interval: The interval (in seconds) to wait before running the storage cleanup thread

API Changes:

Instead of over loading the present createZone API and updateZone API a new API is introduced say "UpdateZoneLevelParamters API".

During the creation of zone default values for these parameters will be set in the data_center_details table.

These can be updated using the "updateZoneLevelParamters" API each at a time by sending the name value pair with zone id.

Schema:

We will add the name value pairs

...

updateZoneLevelParamters

...

Schema:

We will add the name value pairs of these zone level parameters in the data_center_details table*.*

...

1) cluster.cpu.allocated.capacity.disablethreshold: Percentage (as a value between 0 and 1) of cpu utilization above which allocators will disable using the cluster for low cpu available

2) cluster.cpu.allocated.capacity.notificationthreshold: Percentage (as a value between 0 and 1) of cpu utilization above which alerts will be sent about low cpu available

3) cluster.memory.allocated.capacity.disablethreshold: Percentage (as a value between 0 and 1) of memory utilization above which allocators will disable using the cluster for low memory available

4) 4) cluster.memory.allocated.capacity.notificationthreshold: Percentage (as a value between 0 and 1) of memory utilization above which alerts will be sent about low memory available

Here we introduce new API called updateClusterLevelParameters to update the cluster level parameters. During the cluster creation time default values will be set to these parameters, later we can use this API to modify the value as per needed for each cluster.

Schema:

Schema:

We will add the name value pairs of these cluster level parameters in the cluster_details We will add the name value pairs of these cluster level parameters in the cluster_details table as key value pairs*.*

...

1) allow.public.user.templates: If false, users will not be able to create public templates

2) remote.access.2) remote.access.vpn.client.iprange: The range of ips to be allocated to remote access vpn clients. The first ip in the range is used by the VPN server

Here we introduce new API called updateAccountLevelParameters. During the account creation time default values will be set to these parameters, later we can use this API to modify the value as per needed for each account.

Schema:

We will add the name value pairs of these account level parameters in the account_details table as key value pairs*.*

...

1) storage.overprovisioning.factor: Used for storage overprovisioning calculation; available storage will be (actualStorageSize * overprovisioningfactor)

 Here we introduce new API called  Here we introduce new API called updateStorageLevelParameters. During the addition of storage pool default values will be set to these parameters, later we can use this API to modify the value as per needed for each storage.

Schema:

We will add the name value pairs of these storge level parameters in the storage_pool_details table as key value pairs*.*

Here are the global config parameters and their proposed granularity.

(Those are marked in red need clarifications that I have commented in the last column)

Offer additional parameter, link to sec storage capacity: What this actually mean?
account_details table will hold the key, value pair. In RemoteAccessVPNManager we need to take the value from the account_details table, validate it and then use.
CPU/Memory/Storage Notification and Capacity Thresholds:
1) cluster.cpu.allocated.capacity.disablethreshold 
2) cluster.cpu.allocated.capacity.notificationthreshold
3) cluster.memory.allocated.capacity.disablethreshold
4)cluster.memory.allocated.capacity.notificationthreshold
5) pool.storage.allocated.capacity.disablethreshold
6) pool.storage.capacity.disablethreshold
CPU and Memory notification and capacity threshold values per cluster can be stored in the cluster_details table and these values can be used during capacity checking and raising alerts. Since as part of CPU and RAM overcommit feature cpu and ram are made at cluster level, so changing the notifications and capacity thresholds per cluster seems to be relevant.
1) Storage Notification and Capacity Thresholds ---- per CLUSTER
2) Storage Limit per Pool ---- per ZONE
There is clash between the requirements, Which one I need to look into?
Does this mean overprovisioning factors?
If it is the case, we have already planned to make it at cluster level. Do we need both?

Global Parameter	Global Parameter	Description	Proposed change	Development	Comments or clarifications needed
allow.public.user.templates	If false, users will not be able to create public templates.	Per Account, overrides the global, e.g. for resellers not end customers	The implementation goes like adding value in the account_details table. Whenever public template is created we need to check in the account details table and then proceed.
max storage.accountoverprovisioning.snapshots	The default maximum number of snapshots that can be created for an account	Offer additional parameter, link to sec storage capacity, per account	This is already been maintained and checked with account id, we need to take the value while creating an account.
max.account.templates	The default maximum number of templates that can be deployed for an account	As per snapshots, ensure it includes ISOs	This is already been maintained and checked with account id, we need to take the value while creating an account.	Same as the max.account.snapshots/templates
max.account.user.vms	The default maximum number of user VMs that can be deployed for an account	n/a		Does this mean to skip the parameter?
max.account.volumes	The default maximum number of volumes that can be created for an account	This should refer to data vols, sys vols should be inherent from user VMs		will this change comes under this feature. This more like a bug.
max.template.iso.size	The maximum size for a downloaded template or ISO (in GB).	per account, also limited by sec storage - see snapshots, templates. So perhaps a new global/per account setting for max sec storage		Same as the max.account.snapshots/templates
mem.overprovisioning.factor	Used for memory overprovisioning calculation	per cluster, overrides global		This is done as part of cpu and ram overcommit feature
cpu.overprovisioning.factor	Used for CPU overprovisioning calculation; available CPU will be (actualCpuCapacity * cpu.overprovisioning.factor)	per cluster, overrides global		This is done as part of cpu and ram overcommit feature
storage.overprovisioning.factor	Used for storage overprovisioning calculation; available storage will be (actualStorageSize * storage.overprovisioning.factor)	per storage (per sysvol/datavol usage), overrides global	storage_pool_table will hold the key value pair of storage overprovisioning factor. During the check whether the storage pool has enough space for the volume we need to consider per storage level overprovisioning factor and while creating and updating the capacity entry in the for the storage.
remote.access.vpn.client.iprange	The range of ips to be allocated to remote access vpn clients. The first ip in the range is used by the VPN server	Per Account, overrides the global
factor	Used for storage overprovisioning calculation; available storage will be (actualStorageSize * storage.overprovisioning.factor)	per storage (per sysvol/datavol usage), overrides global	storage_pool_table will hold the key value pair of storage overprovisioning factor. During the check whether the storage pool has enough space for the volume we need to consider per storage level overprovisioning factor and while creating and updating the capacity entry in the for the storage.
remote.access.vpn.client.iprange	The range of ips to be allocated to remote access vpn clients. The first ip in the range is used by the VPN server	Per Account, overrides the global	account_details table will hold the key, value pair. In RemoteAccessVPNManager we need to take the value from the account_details table, validate it and then use.
storage.cleanup.interval	The interval (in seconds) to wait before running the storage cleanup thread.	Per AZ, eg for Private/Reseller AZ to offer differing storage service		Do we need to run different storage GC threads for different zones? Or start single thread with the global value and within that check for each zone whether the interval is completed by storing the last cleanup time per zone and current time. If completed clenup the storage otherwise skip the zone ?
CPU/Memory/Storage Notification and Capacity Thresholds: 1) cluster.cpu.allocated.capacity.disablethreshold  2) cluster.cpu.allocated.capacity.notificationthreshold 3) cluster.memory.allocated.capacity.disablethreshold 4)cluster.memory.allocated.capacity.notificationthreshold 5) pool.storage.allocated.capacity.disablethreshold 6) pool.storage.capacity.disablethreshold		Per cluster	CPU and Memory notification and capacity threshold values per cluster can be stored in the cluster_details table and these values can be used during capacity checking and raising alerts. Since as part of CPU and RAM overcommit feature cpu and ram are made at cluster level, so changing the notifications and capacity thresholds per cluster seems to be relevant
storage.cleanup.interval	The interval (in seconds) to wait before running the storage cleanup thread.	Per AZ, eg for Private/Reseller AZ to offer differing storage service		Do we need to run different storage GC threads for different zones? Or start single thread with the global value and within that check for each zone whether the interval is completed by storing the last cleanup time per zone and current time. If completed clenup the storage otherwise skip the zone ?
	Per cluster	Storage Limit per Pool: 1) pool.storage.allocated.capacity.disablethreshold 2) pool.storage.capacity.disablethreshold	1) Percentage (as a value between 0 and 1) of allocated storage utilization above which allocators will disable using the pool for low allocated storage available. 2) Percentage (as a value between 0 and 1) of storage utilization above which allocators will disable using the pool for low storage available.	Per Zone	data_center_details table holds the 'name, value' pairs of these parameters. In Storagemanager, while checking the storage pool whether it has enough space for the vm's root disk or data disk, we need to consider the zone in which pool exists and get the details from the data_center_details table accordingly.	Oversubscription Ratio		Per Zone		Local Storage support		Per Zone		Currently this support is there for zone level.
VM Allocation Algorithm: vm.allocation.algorithm	If 'random', hosts within a pod will be randomly considered for VM/volume allocation. If 'firstfit', they will be considered on a first-fit basis.	Per Zone	data_center_details table holds the 'name, value' pairs of these parameters. During the allocation for VM/volume this value corresponding to zone is to be considered. Logic need to be changed for volume allocation too since it also allocation based on this paramter.
VR Network Throttling Rate: network.throttling.rate	Default data transfer rate in megabits per second allowed in network	Per Zone	For the domRs Guest and Public networks we take network throttling from the corresponding Guest Virtual networkOffering. In case the value is not specified in the network offering it should consider the value from the global parameter network.throttling.rate. But right now there is a bug that noticed, guest and public networks are always considering network rate from the global parameter. Apart from this, we need to store this value per each zone and in the router vm life cycle we need to consider the zone level parameter. This value can be stored in the datacenter details table	In case of user VMs for non default network the throttling rate is considered from the network offering, if this is not specified it considers the value from global value network.throttling.rate. For default network it consider value from vm.network.throttling.rate. Since both these parameters(network.throttling.rate, vm.network.throttling.rate) are considered in case of guest vm networks, Is that fine to change only network.throttling.rate per zone?
Router Template ID: router.template.id	Default ID for template	Per Zone	In the current implementation, the details of the templates are stored in the vm_templates table. These include all systemVM templates for all hypervisors, During the router vm deployment it gets the list of templates based on the hypervisor type and takes the 1st template from the list. Otherwise we are not using this parameter to select the template. So the task is to make this paramter work and provide the value per zone. Design: In the datacenter_details table we maintain the router.template.id for each hypervisor. During the router vm deployment we consider the template id from this table based on the hypervisor type
Guest Domain Suffix : guest.domain.suffix	Default domain name for vms inside virtualized networks fronted by router	Per Zone	The value can be stored in the data_center_details_table and  during guest network and vpc creation we can consider the value per zone level from the data_center_details table. In the PRD the parameter mentioned is guest.domain.prefix. But there is no such parameter.  I hope this is guest.domain.suffix.
External DNS Usage: use.external.dns	Bypass internal dns, use external dns1 and dns2	Per Zone	The value can be stored in the data_center_details table and during finalizing the virtual machine's profile this value can be taken per zone corresponding to the deploy destination of the vm.

...