I covered leases in my previous post on vCloud Director Policies and will be covering quotas and limits in this post.
Quotas
Quotas are used to limit the number of VMs a user can have in the org. Quotas come in two flavors, the stored VM quota, which limits the number of VMs a user can have in the org and the running VM quota which limits the number of VMs that a user can have running in the org. While it’s possible to set the running VM quota to higher then the stored VM quota (at least in 1.5.1), every VM in the org counts against the stored VM quota. Meaning the stored VM quota is the maximum number of VMs a user can have in the org. I.e. A user with a stored VM quota of 10 and a running VM quota of 15, would only be able to have 10 VMs in the org.
The default storage VM and running VM quotas are configured at the org level, but this just sets the the quotes for new users added to the org. So for example if you set the quotas for an org to 20 stored VMs and 10 running VMs, then each user added to that org will have a quota of 20 storage and 10 running. If you have 10 users in the org, then the org could have up to 200 stored VMs and 100 running VMs.
If you change the quota at the org level, say you lowered the number of running VMs to 5, then only new uses will have that quota, all existing users will still have a running VM quota of 10. To further make the point, a user’s quota does not have to match the org defaults and can be set to what ever the org admins feel is appropriate for that user.
This makes the application of quotas much different then leases. Leases are set at the org level and apply to all users, well leases really apply to vApps, but vApps are created by users. Where quotas are set on a user by user basis and two users could have very different quota settings.
Quotas in general don’t seem all that useful, except for maybe in a Pay As You Go model. But even then, since quotas are an org level configuration, instead of a org vDC level configuration, you could quickly complicate things by having an org with vDCs using both PAYGO and Allocation models, then what?
Limits
Limits are set at an org level to help prevent prevent a DoS attack and generally ensure a single user can’t tax the cloud too much. Three different limits can be set, with two of them limiting the number of resource intensive operations and one of them limiting the number of VMRC console connections to a VM.
The limits to the number of resource intensive operations are set as a per user number and a per org number. So you could set the limit for the number of resource intensive operations to 3 per user and 6 per org. In this configuration two users could run 3 resource intensive operations without issue, but if another user tried to start a resource intensive operation they would receive an error stating the maximum number of simultaneous operations has been reached.
The next logical questions is what counts as a resource intensive operation and I can’t find a definitive list. Examples such as copy, move, Add to My Cloud and Add to Catalog are given in the UI. So it sounds like mostly provisioning type activities.
The last limit is the number of simultaneous connections per VM. And by connections it means VMRC connections. Since VMRC connections are proxied by the vCD cell, limiting the number of connections can help ensure your cells don’t get overloaded. This is a somewhat poor protection from someone trying to DoS your cloud by opening a ton of VMRC connections. Even if the number of connections was limited to 1, an attacker could spawn a ton of VMs and open a VMRC connection to each one. So only with reasonable quotas (what can be set/changed by an Org Admin) can the limit to the number of connections provide any type of protection.
One last point is that limits are set by the system administrator and can not be modified by an Org Admin.
Storage Limits
Storage Limits are a bit different then the Limits above since they apply to an Org VDC instead of an org as a whole. A storage limit does what it sounds like, it limits the amount of storage that can by used by an Org VDC.
The primary consumer of Org VDC storage space are vApps, but vApp templates & media also consume space and are counted towards the limit.
Storage limits, like the Org limits described above, are set by a system administrator and can not be modified by an Org Admin.
