...

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

-          A compute service offering could let an end-user select if dedication is required or not

-          Any zone can have “implicit” dedication flag on or off – this flag’s description will be clarified below

...

• 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

...

-          Only VMs that are requested with dedication flag can use those dedicated resources

-          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

-          Optionally, if implicit dedication flag is set for a zone, a new, unused host is found for fulfilling this request and added to the list of "dedicated" resource for this account and will be used for future fulfillment

• ; 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

• 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