Page History

...

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 that domain can share the hosts (as long as they DeployVM with dedication flag on), 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 on).
• Alternatively, a host or cluster or pod or zone can be "implicitly" dedicated - this flag's description will be clarified below
• 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 utilization
• A service offering can optionally have an "implicitly" dedicated flag on - this flag's description will be clarified below in the table

• 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

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

  	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

Logs

1. Ensure proper logs are maintained into vmops.log and api.log

...

1. Dedicated resources can only be used if service offering dedication flag is ON .
2. If resources are exhausted within a domain, VM deployment should fail if the Implicit dedication flag is OFF.

Configuration

1. global configuration parameter addition: implicit.dedication.enable, default value for this is ONor DeployVM dedication flag is ON but not both.

User Permissions

1. Only Root Admin will have the privilege to dedicate 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 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. Only Root Admin can change the global parameter:  implicit.dedication.enableUser/admin can enable the DeplovVM dedication flag. 

Use Cases: 

Dedicating resources to Domain/Account

...