Feature: Private host, cluster, pod

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 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 "implicity" dedicated - this flag's description will be clarified below

-          A service offering can optionally have an "implictly" 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 (implict 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

-          Only VMs that are requested with dedication flag (implicit or explicit) can use those dedicated resources

-          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)

-          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