The vCloud Director placement engine determines what resources, including resource pools, datastores, and networks or network pools, on which to place the virtual machines in a vApp. The placement decision is made independently for each virtual machine in a vApp based on the requirements of that virtual machine.
- When you create a vApp, the placement engine determines what resource pool, datastore, and network pool on which to place the vApp's virtual machines.
- When you start a vApp, the placement engine might selectively move the vApp's virtual machines to another resource pool, datastore, or network pool if the current resource pool, datastore, or network pool lacks sufficient resources for the vApp to power on.
- When you change the storage policy of a virtual machine, the placement engine moves the virtual machine to a datastore and resource pool that support the new storage policy.
- When virtual machines are migrated to different resource pools.
- CPU capacity
- Memory capacity
- Number of virtual CPUs
- Hardware version supported by the host
The placement engine filters out disabled resource pools from the candidate list so that no virtual machine is created on a disabled resource pool. When possible, the placement engine places virtual machines on the same hub as other virtual machines in the organization virtual datacenter.
- Storage capacity
- Storage policy
The placement engine filters out disabled datastores from the candidate list so that no virtual machine is created on a disabled datastore.
The placement engine uses the network name to select candidate network pools for a vApp and its virtual machines.
After the placement engine selects a set of candidate resources, it ranks the resources and picks the best location for each virtual machine based on the CPU, virtual RAM, and storage configuration of each virtual machine.
While ranking resources, the placement engine examines the current and estimated future resource use. Estimated future use is calculated based on powered-off virtual machines currently placed on a given resource pool and their expected use after they are powered on. For CPU and memory, the placement engine looks at the current unreserved capacity, the maximum use, and the estimated future unreserved capacity. For storage, it looks at the aggregated provisioned capacity provided by the cluster that each resource pool belongs to. The placement engine then considers the weighted metrics of the current and future suitability of each resource pool.
The placement engine favors resource pools that provide the minimum of unreserved capacity for CPU and memory and free capacity for storage. It also gives lower preference to yellow clusters so that yellow clusters are only selected if no healthy cluster is available that satisfies the placement criteria.
When a virtual machine is powered on, either as part of starting a vApp or on its own, the placement engine runs to validate that the resource pool the virtual machine is assigned to has sufficient resources to support the requirements of the virtual machine. This step is necessary because the resource availability on the resource pool might have changed since the virtual machine was created on the resource pool. If the resource pool lacks sufficient capacity to power on the virtual machine, the placement engine finds another compatible resource pool on the provider virtual datacenter that satisfies the requirements of the virtual machine and places the virtual machine there. This substitution might result in the migration of the virtual machine's VMDKs to a different datastore if no suitable resource pools are connected to the datastore the VMDKs are located on.
During concurrent deployment situations when a resource pool is close to capacity, the validation of that resource pool might succeed even though the resource pool lacks the resources to support the virtual machine. In these cases, the virtual machine cannot power on. If a virtual machine fails to power on in this situation, start the power on operation again to prompt the placement engine to migrate the virtual machine to a different resource pool.
When the cluster that a resource pool belongs to is close to capacity, a virtual machine on that resource pool might still be able to power on even when no individual host has the capacity to power on the virtual machine. This happens as a result of capacity fragmentation at the cluster level. In such cases, a system administrator should migrate a few virtual machines out of the cluster so that the cluster maintains sufficient capacity.