Knowledge Base

Overview of Elastic vDC

• Only the Pay-As-You-Go organization vDCs. The Reservation Pool and Allocation Pool vDC are still bound to a single provider vDC resource pool.
• A single vCenter Server Datacenter (provider vDC resource pools cannot span multiple vCenter Server Datacenters)

The system administrator is allowed to add/remove multiple resource pools to/from an existing Provider vDC, thus making it possible for a Provider vDC to be backed by multiple resource pools. When the provider vDC is created, user selects a primary resource pool. Allocation Pool and Reservation Pool organization vDCs consume resources from this primary resource pool. After creating the provider vDC, additional resource pools can be added to the provider vDC, so that Pay-As-You-Go organization vDCs using that provider vDC can expand, as required, to accommodate more virtual machines.

Resource pool selection during vApp placement

When a vApp is deployed in the Pay-As-You-Go organization vDC, vCloud Director selects the appropriate resource pool from the list of resource pools available to the provider vDC.

Resource Pool Viability for vApp Placement

For a resource pool to be considered viable for vApp placement, it must satisfy these conditions:

• It should be in an enabled state.
• It should have connected and enabled datastores, with sufficient free capacity to place all virtual machines in the vApp. If the organization vDC is thin provisioned, this criterion is not applicable.
• It should be connected to the same networks as those available from the primary provider vDC resource pool. This is to ensure that vApps deployed within an Organization can communicate via the same network.
• It should have sufficient free CPU and Memory capacity to power-on the vApp. However, if no resource pools can be found satisfying this criterion, vApp creation is allowed on the “least worst” resource pool.

Selection mechanism from the viable resource pools

• Compute metric
  
  The compute metric is intuitively designed to reflect the number of vApps that can be provisioned on the given resource pool, based on the vApps’ compute requirement. It is computed as:
  
  Resource_pool_unreserved_Mhz / vApp_vCPU_Allocation_In_Mhz
  
  
• Memory metric
  
  The memory metric attempts to reflect the number of vApps that can be provisioned on the given resource pool, based on the vApps’ memory requirement. It is computed as:
  
  Resource_pool_unreserved_Memory_MB / vApp_Memory_Allocation_In_MB
  
  
• Storage metric
  
  The storage metric attempts to reflect the number of vApps that can be provisioned on the given resource pool, while comparing the sum of storage capacity available to the resource pool against the vApps’ expected storage requirement. It is computed as:
  
  Sum of storage capacity on datastores connected to Resource Pool in MB / vApp Storage requirement in MB

• Resource pool resgroup-447 is viable, capacity metrics: {COMPUTE_MHZ=3.476, MEMORY_MB=2.33984375, STORAGE_MB=9.700439453125}
• Resource pool resgroup-76 is viable, capacity metrics: {COMPUTE_MHZ=3.952, MEMORY_MB=1.212890625, STORAGE_MB=13.506323242187499}

Limitations

• Only Pay-As-You-Go organization vDCs are elastic.
• All the virtual machines in a vApp are placed in the same resource pool. Therefore, after a vApp is deployed to a resource pool, subsequent virtual machine provisioning operations within that vApp always go to that same resource pool.

Best Practices and Deployment Recommendations

It is recommended that shared storage be used and made available to all clusters of an Elastic Provider vDC. This helps in avoiding fragmentation of storage resources as virtual machines are deployed to individual clusters. Also, this design enables greater mobility of virtual machines across different clusters in an Elastic Provider vDC.