[
https://issues.apache.org/jira/browse/CLOUDSTACK-818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13752210#comment-13752210
]
Jessica Tomechak edited comment on CLOUDSTACK-818 at 8/28/13 4:10 PM:
----------------------------------------------------------------------
For ease of reviewing, here is the full draft:
Dedicating Resources to Accounts and Domains
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. Only users in that domain or
its subdomain may use the infrastructure. For example, only users in a given
domain can create guests in a zone dedicated to that domain.
There are several types of dedication available:
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.
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 Affinity Groups). 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).
CloudStack 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 CloudStack 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.
was (Author: jtomechak):
For ease of reviewing, here is the full draft:
Dedicating Resources to Accounts and Domains
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. Only users in that domain or
its subdomain may use the infrastructure. For example, only users in a given
domain can create guests in a zone dedicated to that domain.
There are several types of dedication available:
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.
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 Affinity Groups). 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).
CloudPlatform 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 CloudPlatform 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.
> Document Dedicate Pod, Cluster or Host to a domain
> --------------------------------------------------
>
> Key: CLOUDSTACK-818
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-818
> Project: CloudStack
> Issue Type: Sub-task
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Doc
> Reporter: Radhika Nair
> Assignee: Jessica Tomechak
> Fix For: 4.2.0
>
>
> Dedicate Pod, Cluster or Host to a domain- Documentation
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
