...

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

...

-          Alternatively, a host or cluster or pod or zone can be "implicitly" dedicated - 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

...

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

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

-          at this time, there is no requirement for the domain/sub-domain admins to manage the resource - the root admin will remain the owner of the resources