Page History

...

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
• 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 DeployVM with dedication flag on), 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 DeployVM with dedication flag on).

• Alternatively, a host or cluster or pod or zone can be "implicitly" dedicated - this flag's description will be clarified below

...

• Implicit dedication can be for a zone/pod/cluster/host, but not associated with any domain or account; however, during VM deployment, once chosen, 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. However, pre-allocating specific (number of) hosts to each account is not desired as this will create forecasting issues/sub-optimal utilization
• A service offering can optionally have an "implicitly" dedicated flag on - 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

-          Only VMs that belong to the domain/sub-domain/accounts should be deployed/started on the dedicated (implicit and explicit) hosts under the zone/pod/cluster/host

-           if a "non-dedicated" VM is requested and there is no space available from non-dedicated area in the cloud, the request must fail, even if there is space in the dedicated area

• in the table

• 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

-          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

• Fail the request if DeployVM dedication Flag is specified and SO has implicit dedication ON
• When you search implicitly dedicated “area” for a host (second table below), if there is already a host for this account, pick it up (instead of finding a new one every time)
• When you delete the last VM from a host in the implicit area, remove the association of the account with the host (i.e. make it implicit-free host as before)

...

• 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

...