Page History

...

3. Shared Resources: All the non-dedicated resources.

4. SO dedication flag: a new Parameter in Service Offering. if ON, Use Implicitly Dedicated Resources 

5. DVM dedication flag: a new Parameter in deployVirtualMachine API, if ON, VM is deployed on explicitly dedicated resources

This new parameter has above 4 and 5 parameters have been removed as per discussion.

For Implicit Dedication, 

1.  Strict Implicit dedication, a new type in Affinity Groups An "explicit dedication" type will be added in Affinity type which will indicate deployment on explicitly dedicated resources. 

Feature Specifications

Requirements

host having VMs of same account. 

2. Preferred Implicit dedication, a new type in Affinity Groups will indicate deployment on host having VMs of same account if possible, otherwise can be place in shared resources

For Explicit Dedication,

3. Explicit dedication, a new type will be added in Affinity Groups which will indicate deployment on explicitly dedicated resources. 

Feature Specifications

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
• 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 ondeploy a VM requesting dedication), 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 ondeploy a VM requesting dedication).
• AlternativelyOptionally, a host or cluster or pod or zone can be "implicitly" dedicated - this flag's description will be clarified below
• Strict Implicit dedication, when requested, means, a host will not be shared across multiple accounts 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 utilizationA service offering can optionally have an "implicitly" dedicated flag on - this flag's description will be clarified below in the table
• Preferred Implicit Dedication, when requested, means VM would prefer to share a host with another VM of this account, if possible, but could be placed with another account's VM, if needed

• 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

• 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

• Table 1:Deploying VM with Explicit Dedication

  	VM requesting dedication	VM NOT requesting dedication
  Explicitly Dedicated Resources	Pick from Explicitly dedicated else fail

• 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)
• Table 1:Deploying VM with DeployVM dedication flag

  	DeployVM dedication Flag specified	DeployVM dedication Flag Not specified
  Explicitly Dedicated Resources	Pick from Explicitly dedicated else fail	Pick from shared resources else fail
  NO Explicitly Dedicated Resources	Fail the request	Pick from shared resources else fail

• Table 2: Deploying VM with SO dedication flag

  	SO dedication Flag =  ON	SO dedication Flag =  OFF
  YES - Implicitly Dedicated Resources	Pick from implicit dedicated resources else FAIL	Pick from shared resources else fail
  NO - Implicitly Explicitly Dedicated Resources	Fail the request	Pick from shared resources else fail

...

1. Only Root Admin can dedicate zone, pod, cluster or host to specific domain or an account.
2. Only Root admin can implicitly dedicate a zone, pod, cluster or a host.
3. If a user does not belong to a domain which has explicitly dedicated resources, he cannot access the pod, cluster or host dedicated to that domain/account.
4. Users belonging to domain/account having dedicated resources, can access them but should not be allowed to modify.
5. 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
6. Only Root Admin can add a service offering with "isdedicated" option enabled. 
7. User/admin can enable the DeplovVM dedication flag. 

Use Cases: 

VM Deployment

The following figure graphically illustrates the allocation of hosts for VM deployment.

...