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.
vCloud Director VM-Host affinity rules are user-specified constraints that the system considers during the deployment process. There are two types, or polarities, of VM-Host affinity rules:
You can make an affinity rule mandatory to specify that VM deployment must fail unless the specified placement objective can be achieved. When a virtual machine and host are the subject of a mandatory affinity rule, placement requirements dictated by the rule override any placement changes that might be initiated by vSphere services such as high availability and Storage DRS.
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.
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.
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.
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.
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.
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 View and Modify Organization VDC Compute Policies and Retrieve or Update the VDC Compute Policy of a Virtual Machine.