A vCloud Director system administrator can create groups of VMs in a resource pool, then use VM-Host affinity rules to specify whether members of a VM group should be deployed on members of a vSphere host DRS Group.
vCloud Director VM-Host affinity rules provide vCloud Director system administrators with a way to specify how vSphere Distributed Resource Scheduler (DRS) should place VMs on hosts in a resource pool. VM-Host affinity rules can be useful when host-based licensing requires VMs that are running certain applications to be placed on hosts that are licensed to run those applications. They can also be useful when virtual machines with workload-specific configurations require placement on hosts that have certain characteristics. The technical white paper Best Practices for Performance Tuning of Telco and NFV Workloads in vSphere (http://www.vmware.com/files/pdf/techpaper/vmware-tuning-telco-nfv-workloads-vsphere.pdf) provides several examples of virtual machine configurations that require specific host properties.
Starting with vCloud Director 9.5, service providers can expose VM groups to tenants by using VDC compute policies.
Host Groups and VM Groups
A vSphere VM-Host affinity rule is a rule of type Virtual Machines to Hosts, and must specify a host group and a VM group. Before a vCloud Director system administrator can create a VM-Host affinity rule, a vSphere administrator must create at least one host DRS group in a resource pool mapped to a vCloud Director Provider VDC, and a vSphere administrator or vCloud Director system administrator must create a VM group in the same resource pool. VM-Host affinity rules express an affinity in all members of a VM group for all hosts in a host DRS group, so all hosts in a group should share one or more characteristics that a VM can require from a host. For example, you can group hosts on the basis of the application licenses they carry, and group VMs on the basis of the application licenses they require. You can then create VM-Host affinity rules that place VMs on hosts that carry the required licenses.
Because VM-Host affinity rules are properties of a resource pool, all members of groups that are subject to a rule must be deployed in the same resource pool. If a virtual machine or host is removed from the resource pool, the system removes it from any host group or VM group of which it is a member. The system does not update the group when the host or VM is returned to the resource pool.
Affinity Rule Interactions and Conflicts
All VM-Host affinity rules in a resource pool have the same precedence. This configuration has implications for how the rules interact. For example, a virtual machine that is a member of two VM groups, each of which is named in a different required VM-Host rule, can run only on hosts that belong to both of those host groups. When you create a VM-Host affinity rule, the system does not check for potential interactions of this kind.
The system does check for conflicts that could arise when applying multiple mandatory rules. For example, if you group VMs and hosts in a way that enables you to create a mandatory anti-affinity rule that applies to a VM and a host that are members of other groups that are subject to a different mandatory affinity rule, the system cannot apply to either rule. When two or more VM-Host affinity rules conflict in this way, the system applies the oldest rule and disables the others. You can correct the problem by making the rules optional, or by grouping the VMs and hosts in ways that minimize the chances of this sort of mandatory rule conflict occurring.
Affinity Rules and vSphere Resource Management
vSphere resource management features such as DRS, vSphere HA, and vSphere DPM never take any action that can violate a mandatory VM-Host affinity rule.
- DRS does not evacuate virtual machines to place a host in maintenance mode.
- DRS does not place virtual machines for power-on or load balance virtual machines.
- vSphere HA does not perform failovers.
- vSphere DPM does not optimize power management by placing hosts into standby mode.
To avoid these situations, be careful when you create more than one mandatory affinity rule that affects a specific VM-host pair. Be sure that the resource pool contains enough hosts so that losing a host does not leave the system with no host on which a VM that is governed by a rule can run. Rules that are not mandatory can be violated to allow the proper functioning of DRS, vSphere HA, and vSphere DPM.
VDC Compute Policies
A VDC compute policy is a collection of VM groups of a similar type that belong to different clusters. A VDC compute policy can have zero or one VM group from each cluster. For example, the compute policy oracle_license can comprise VM groups oracle_license1 and oracle_license2, where VM group oracle_license1 belongs to cluster oracle_cluster1, and VM group oracle_license2 belongs to cluster oracle_cluster2.
When you assign a VDC compute policy to a VM, the placement engine adds this VM to the corresponding VM group of the cluster on which it resides. For example, if you select to deploy a VM on cluster oracle_cluster1 and assign the compute policy oracle_license to this VM, the placement engine adds the VM to VM group oracle_license1.
The workflow is the following.
- A system administrator creates one or more compute policies at a provider VDC level by using the vCloud OpenAPI.
- A system administrator creates one or more global VDC compute policies by using the vCloud OpenAPI.
A global VDC compute policy can be associated with zero or one provider VDC compute policy. Global VDC compute policies are unique by name and provider VDC compute policy.
- A system administrator publishes a global VDC compute policy to one or more organization VDCs by using the vCloud OpenAPI.
Tenants can see only the VDC compute policies that are published to their organization VDCs. Provider VDC compute policies are not available at a tenant level.
- Tenants can use the vCloud API to assign a VDC compute policy to a VM by including the VdcComputePolicy element when creating or updating a VM, when composing, recomposing, capturing, or instantiating a vApp template, and when cloning or moving a vApp or VM.
Initially, the system does not contain any provider VDC compute policies, and each organization VDC contains only a default compute policy, which is not associated with a provider VDC compute policy.
To create and manage provider and global VDC compute policies, you must use the vCloud OpenAPI. See Getting Started with vCloud OpenAPI at https://code.vmware.com.
To view and modify VDC compute policies, you must use the vCloud API. See vCloud API Programming Guide for Service Providers.