diff --git a/docs/en-US/accounts-users-domains.xml b/docs/en-US/accounts-users-domains.xml
index 34372a7871c..e8b08a78ee9 100644
--- a/docs/en-US/accounts-users-domains.xml
+++ b/docs/en-US/accounts-users-domains.xml
@@ -51,12 +51,14 @@
Resources belong to the account, not individual users in that account. For example,
billing, resource limits, and so on are maintained by the account, not the users. A user can
operate on any resource in the account provided the user has privileges for that operation.
- The privileges are determined by the role.
+ The privileges are determined by the role.
+ A root administrator can change the ownership of any virtual machine, network,
+ data disk, snapshot, template, or ISO from one account to any other account. A domain or
+ sub-domain administrator can do the same for items within the domain from one account to
+ any other account in the domain.
-
+
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.
+
+
diff --git a/docs/en-US/images/dedicate-resource-button.png b/docs/en-US/images/dedicate-resource-button.png
new file mode 100644
index 00000000000..0ac38e00eca
Binary files /dev/null and b/docs/en-US/images/dedicate-resource-button.png differ