Dedicating Resources to Accounts and Domains

Dedicating Resources to Accounts and Domains - You can dedicate infrastructure resources including zones, pods, clusters, or hosts to an account or domain. - The root administrator can dedicate resources to a specific domain or account that needs private infrastructure for additional security or performance guarantees. A zone, pod, cluster, or host can be reserved by the root administrator for a specific domain or account. @@ -65,14 +67,67 @@ There are several types of dedication available: - To explicitly dedicate a resource, use the explicit-dedicated type of Affinity Group. - For example, when creating a new VM, an end user can choose to place it on dedicated infrastructure. - See . - You can also use strict implicit dedication. - 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. - You can also implicitly dedicate a resource with "preferred" implicit dedication. This means that the resource will be deployed - in dedicated infrastructure if possible. Otherwise, the resource can be deployed in shared infrastructure. + Explicit dedication. A zone, pod, cluster, or host is dedicated to an account or + domain by the root administrator during initial deployment and + configuration. + Strict implicit dedication. A host will not be shared across multiple accounts. For example, + strict implicit dedication is useful for deployment of certain types of + applications, such as desktops, where no host can be shared + between different accounts without violating the desktop software's terms of license. + Preferred implicit dedication. The VM will be deployed in dedicated infrastructure if + possible. Otherwise, the VM can be deployed in shared + infrastructure. +

+ How to Dedicate a Zone, Cluster, Pod, or Host to an Account or Domain + For explicit dedication: When deploying a new zone, pod, cluster, or host, the + root administrator can click the Dedicated checkbox, then choose a domain or account + to own the resource. + To explicitly dedicate an existing zone, pod, cluster, or host: log in as the root admin, + find the resource in the UI, and click the Dedicate button. + + + + + dedicate-resource-button.png: button to dedicate a zone, pod, cluster, or host + + + For implicit dedication: The administrator creates a compute service offering and + in the Deployment Planner field, chooses ImplicitDedicationPlanner. Then in Planner + Mode, the administrator specifies either Strict or Preferred, depending on whether + it is permissible to allow some use of shared resources when dedicated resources are + not available. Whenever a user creates a VM based on this service offering, it is + allocated on one of the dedicated hosts. +

+ How to Use Dedicated Hosts + To use an explicitly dedicated host, use the explicit-dedicated type of affinity + group (see ). For example, when creating a new VM, + an end user can choose to place it on dedicated infrastructure. This operation will + succeed only if some infrastructure has already been assigned as dedicated to the + user's account or domain. +

+ Behavior of Dedicated Hosts, Clusters, Pods, and Zones + The administrator can live migrate VMs away from dedicated hosts if desired, whether the destination + is a host reserved for a different account/domain or a host that is shared (not dedicated to any particular account or domain). + &PRODUCT; will generate an alert, but the operation is allowed. + Dedicated hosts can be used in conjunction with host tags. If both a host tag and dedication are requested, + the VM will be placed only on a host that meets both requirements. If there is no dedicated resource available + to that user that also has the host tag requested by the user, then the VM will not deploy. + If you delete an account or domain, any hosts, clusters, pods, and zones that were + dedicated to it are freed up. They will now be available to be shared by any account + or domain, or the administrator may choose to re-dedicate them to a different + account or domain. + System VMs and virtual routers affect the behavior of host dedication. + System VMs and virtual routers are owned by the &PRODUCT; system account, + and they can be deployed on any host. They do not adhere to explicit dedication. + The presence of system vms and virtual routers on a host makes it unsuitable for strict implicit dedication. + The host can not be used for strict implicit dedication, + because the host already has VMs of a specific account (the default system account). + However, a host with system VMs or virtual routers can be used + for preferred implicit dedication. + +