From 6bd18d99813823bd6f2e036947f1dfb7ebbed815 Mon Sep 17 00:00:00 2001 From: Radhika PC Date: Mon, 22 Apr 2013 17:54:16 +0530 Subject: [PATCH] CLOUDSTACK-1563 --- docs/en-US/limit-accounts-domains.xml | 98 +++++++++++---------------- 1 file changed, 41 insertions(+), 57 deletions(-) diff --git a/docs/en-US/limit-accounts-domains.xml b/docs/en-US/limit-accounts-domains.xml index da45dabc982..a864ee27ef3 100644 --- a/docs/en-US/limit-accounts-domains.xml +++ b/docs/en-US/limit-accounts-domains.xml @@ -21,15 +21,12 @@ -->
Limiting Resource Usage - In addition to VMs, volumes, and snapshots, &PRODUCT; allows you limit resource types, such - as CPU, RAM, Primary storage, Secondary storage, and Network Rate. - Previously in &PRODUCT;, resource usage limit was imposed based on the resource count, that - is, restrict a user or domain on the basis of the number of VMs, volumes, or snapshots used. A - new set of resource types has been added to the existing pool of resources (VMs, Volumes, and - Snapshots) to support the customization model—need-basis usage, such as large VM or small - VM. The new resource types are now broadly classified as CPU, RAM, Primary storage, Secondary - storage, and Network Rate. &PRODUCT; now allows the root administrator to impose resource usage - limit by the following resource types for Domain, Project and Accounts. + &PRODUCT; allows you to control resource usage based on the types of resources, such as CPU, + RAM, Primary storage, and Secondary storage. A new set of resource types has been added to the + existing pool of resources to support the new customization model—need-basis usage, such + as large VM or small VM. The new resource types are now broadly classified as CPU, RAM, Primary + storage, and Secondary storage. The root administrator is able to impose resource usage limit by + the following resource types for Domain, Project, and Accounts. CPUs @@ -43,9 +40,6 @@ Secondary Storage (Snapshots, Templates, ISOs) - - Network Rate (Mbps) - To control the behaviour of this feature, the following configuration parameters have been added: @@ -71,18 +65,13 @@ max.account.primary.storage (GB) Maximum primary storage space that can be used for an account. - Default is 20*10. + Default is 200. max.account.secondary.storage (GB) Maximum secondary storage space that can be used for an account. - Default is 20*20. - - - max.account.network.rate (Mbps) - Maximum network rate that can be used for an account. - Default is 200. + Default is 400. max.project.cpus @@ -102,21 +91,14 @@ max.project.primary.storage (GB) Maximum primary storage space that can be used for an account. - Default is 20*10. + Default is 200. max.project.secondary.storage (GB) Maximum secondary storage space that can be used for an account. - Default is 20*20. - - - - max.project.network.rate (Mbps) - - Maximum network rate that can be used for an account. - Default is 200. + Default is 400. @@ -136,24 +118,24 @@ for the sub-domains and accounts under their own domain or the sub-domains. - Normal users would have privilege to list resource limits. Use the listResourceLimits + The end users will the privilege to list resource limits. Use the listResourceLimits API.
- Use Cases and Considerations + Limit Usage Considerations - When you refer to Primary or Seconday storage space, it implies that the stated size - of the volume and not the physical size— the actual consumed size on disk in case of - thin provisioning. + Primary or Secondary storage space refers to the stated size of the volume and not the + physical size— the actual consumed size on disk in case of thin provisioning. - If admin reduces the resource limit for an account and set it to less than the - resources currently consumed by that account, the existing VMs/templates/volumes are - destroyed. Using those resources, limits are imposed if the user under that account tries - to execute a new operation. For example, the existing behavior in the case of a VM are: + If the admin reduces the resource limit for an account and set it to less than the + resources that are currently being consumed, the existing VMs/templates/volumes are not + destroyed. Limits are imposed only if the user under that account tries to execute a new + operation using any of these resources. For example, the existing behavior in the case of + a VM are: migrateVirtualMachine: The users under that account will be able to migrate the @@ -165,19 +147,19 @@ - For any resource type, if a domain has limit X, sub-domain or accounts under that - domain can have there own limits, but at any point of time the sum of resource allocated - to sub-domain or accounts under the domain should never exceed the value X. - For example, if a domain has the CPU limit of 40 and sub-domain D1 and account A1 can - have limits of 30 each, but at any point of time the resource allocated to D1 and A1 - should not exceed the limit 40. + For any resource type, if a domain has limit X, sub-domains or accounts under that + domain can have there own limits. However, the sum of resource allocated to a sub-domain + or accounts under the domain at any point of time should not exceed the value X. + For example, if a domain has the CPU limit of 40 and the sub-domain D1 and account A1 + can have limits of 30 each, but at any point of time the resource allocated to D1 and A1 + should not exceed the limit of 40. If any operation needs to pass through two of more resource limit check, then the - lower of 2 limits will be enforced, For e.g. if an account has VM limit of 10 and CPU - limit of 20 and user under that account requests 5 VMs of 4 CPUs each, after this user can - deploy 5 more VMs(because VM limit is 10) but user has exhausted his CPU limit and cannot - deploy any more instance. + lower of 2 limits will be enforced, For example: if an account has the VM limit of 10 and + CPU limit of 20, and a user under that account requests 5 VMs of 4 CPUs each. The user + can deploy 5 more VMs because VM limit is 10. However, the user cannot deploy any more + instances because the CPU limit has been exhausted.
@@ -186,9 +168,9 @@ &PRODUCT; allows the configuration of limits on a domain basis. With a domain limit in place, all users still have their account limits. They are additionally limited, as a group, to not exceed the resource limits set on their domain. Domain limits aggregate the usage of - all accounts in the domain as well as all accounts in all sub-domains of that domain. Limits - set at the root domain level apply to the sum of resource usage by the accounts in all domains - and sub-domains below that root domain. + all accounts in the domain as well as all the accounts in all the sub-domains of that domain. + Limits set at the root domain level apply to the sum of resource usage by the accounts in all + the domains and sub-domains below that root domain. To set a domain limit: @@ -278,12 +260,14 @@ - Click Apply. + + Click Apply. +
Default Account Resource Limits - You can limit resource use by accounts. The default limits are set by using global + You can limit resource use by accounts. The default limits are set by using Global configuration parameters, and they affect all accounts within a cloud. The relevant parameters are those beginning with max.account, for example: max.account.snapshots. To override a default limit for a particular account, set a per-account resource @@ -328,8 +312,7 @@ Public IP Limits - The number of public IP addresses that can be used in an - account. + The number of public IP addresses that can be used in an account. The default is 20. @@ -344,8 +327,7 @@ Template Limits - The number of templates that can be registered in an - account. + The number of templates that can be registered in an account. The default is 20. @@ -381,7 +363,9 @@ - Click Apply. + + Click Apply. +