...

Feature: Assign resources to domain/account

Background: Currently, CloudStack allows cloud admins to dedicate a zone to a tenant. While this is useful in certain scenarios, for several end-users this is a very expensive offering. This feature is to enable more economical options, but still preserve several of the benefits of the private zone offering. This feature allows admins to dedicate resources to a specific tenant that needs private infrastructure for additional security or performance guarantees. This feature also allows admins to dedicate resources to resellers. Re-sellers in turn can ‘resell’ the infrastructure to their customers.

Requirements:-         

• Root Admins must be able to explicitly dedicate a zone, pod or cluster or host to a specific domain or account

-          Only VMs that belong to the domain/sub-domain accounts should be deployed/started on the hosts under the zone/pod/cluster

-          If during a VM deploy or start operation, there are no available resources among the hosts dedicated to the account then CloudStack should fail the operation. Appropriate error message should be logged and event generated

-          Optionally, a global setting can allow the VM to be deployed on a parent domain/sub-domain if there is no space available in the account/sub-domain/domain's dedicated resources

• When deploying a VM, end user can optionally specify it to be placed on a dedicated resource
• Explicit dedication can be for a domain or account and can be a zone/pod/cluster/host; for example, if a cluster is explicitly dedicated to a domain, any account in that domain can share the hosts (as long as they deploy a VM requesting dedication), but sharing is limited to accounts within that domain only. As another example, if a cluster is explicitly dedicated to an account, only that account’s VM can use those hosts in the dedicated cluster (as long as they deploy a VM requesting dedication).
• Optionally, a host can be "implicitly" dedicated
• Strict Implicit dedication, when requested, means, a host will not be shared across multiple accounts – as an example, here is a reason: for deployment of certain types of applications, such as desktops, due to licensing reasons, no host can be shared between different accounts.
• Preferred Implicit Dedication, when requested, means VM would prefer to share a host with another VM of this account, if possible, but could be placed with another account's VM, if needed

• Admin must be able to live migrate of such

...

• a VM to a resource not owned by the account

...

• , but an alert must be generated

• Non-requirement: Must be able to dedicate a primary storage to an account

...

• Non-requirement: for the domain/sub-domain admins to manage the resource - the root admin will remain the owner of the resources

The use case that satisfies this requirement is as follows:

Service Provider SP1 sells cloud services to a number of resellers - those resellers themselves will sell to other sub-resellers or end-users.

For this scenario, resellers might want to either dedicate 'n' pods/cluster or hosts (they may not care about a SPECIFIC pod/cluster/host) - SP1 might even ask VAR1 to (pre)pay for this resource (pod/host/cluster) that has been made exclusive to them - irrespective of whether VAR1 is able to find customer to use some/most/all of these resources or not

This feature has the following benefits/characteristics:

...

• Non-requirement: In general, CloudStack must detect and provide warning of inappropriate location for a VM (such as a dedicated VM on a non-dedicated host) - this is not a specific requirement of this feature, but more of a generic requirement