Architecting a vCloud Director Solution : Resource Groups : 6.2 Compute Resource
   
6.2 Compute Resource
The compute resource is represented by a set of vSphere clusters with VMware vSphere High Availability and VMware vSphere Distributed Resource Scheduler™ (DRS) enabled. For details, refer to design considerations in the Architecting a VMware vSphere Compute Platform for Service Providers document.
The following are compute design considerations:
When calculating the required compute capacity, account for virtualization overhead (VMkernel processes including vSAN and NSX, and virtual machine memory overhead) and resources needed for edge gateway virtual appliances, which are not charged against tenant consumption.
VMware recommends not mixing CPU generations within the same service offering (provider VDC) because the customer might have a different performance experience due to vCloud Director allocating CPU based on clock rate in GHz.
Selection of HA admission control policy depends on the required SLA. The only policy that guarantees restart of all workloads from a failed host is “Specify Failover Hosts.”
The number of hyperthreaded physical cores dictates the maximum number of vCPUs that tenants can allocate to their virtual machines.
Due to security implications in multi-tenant environments, disable memory transparent page sharing. For more information, see the VMware Knowledge Base article Additional Transparent Page Sharing Management capabilities in ESXi 5.5, 5.1, and 5.0 patches in Q4, 2014 (2091682) at http://kb.vmware.com/kb/2097593.
Oversubscribed physical memory can cause memory ballooning or hard drive swapping, which can affect other tenants. In the Reservation type allocation model, the tenant can oversubscribe their actual allocated VDC. Therefore, VMware recommends always using Reservation type allocation mode on tenant dedicated hardware.
As of vCloud Director 8.10 and extended in 8.20, you can influence vSphere placement decisions with VM-VM affinity groups (tenant exposed), VM-host affinity groups (only provider exposed) and VM-host tagging through metadata (tenant exposed). While this opens new use cases (clustered workload availability, OS licensing, low latency workloads), it must be accounted for in provider operational practices.