DUE TO SPAM, SIGN-UP IS DISABLED. Goto Selfserve wiki signup and request an account.

DUE TO SPAM, SIGN-UP IS DISABLED. Goto Selfserve wiki signup and request an account.
...
4) network.throttling.rate: Default data transfer rate in megabits per second allowed in network.
5) router.template.id:
This needs to split This parameter was not in use. So removing this parameter and adding 5 parameters per each hypevisor to be able to provide the values for each hypervisor.
router.template.xen: Name of the default router template on Xenserver
...
router.template.lxc: Name of the default router template on LXC
These are initially set to default to SYSTEM template.
Admin can register new routing templates, so that these can be used to deploy router. These templates are marked as ROUTING type in the DB. We introduce a API change in the register/update template so that ADMIN can register ROUTING templates.
This registered template is only used for deploying router(not SSVM and CPVM). SSVM and CPVM uses the default system template.
6) Guest Domain Prefix: Default domain name for vms inside virtualized networks fronted by router
...
API name | Existing API Parameters | New optional API Parameters | API Response |
|---|---|---|---|
updateConfiguration | name: the name of the configuration | zoneid: ID of the zone | updateconfigurationresponse with scope and updated value |
listConfiguration | category: lists configurations by category | zoneid: ID of the zone | listconfigurationsresponse with scope and value at the corresponding scope of the parameters. |
registertemplate/updatetemplate |
| isrouting: true if the template type is routing i.e., if template is used to deploy router |
|
The API change in registerTemplate and updatetemplate is in support of newly introduced zone/global level parameters router.template.xen/vmware/kvm/lxc/hyperv.
The optional parameter isrouting can be set only by root admin.
Here are the global config parameters and their proposed granularity.
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. |
|
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 | 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? |
CPU/Memory/Storage Notification and Capacity Thresholds: |
| 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. | |
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. |
|
VR 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. | 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. |
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. |
|
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. | |
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. |
|
|
|
|
|
|
...