Compute resources and compute resource pools overview

BMC Server Automation is the resource provider for compute resources: physical servers, virtual clusters, virtual hosts, virtual resource pools, and virtual disk repositories. Note that virtual clusters can include virtual hosts, virtual resource pools, and virtual disk repositories, so any resource of those types that are onboarded as part of a virtual cluster will appear in the BMC Cloud Lifecycle Management Administration Console as both its own resource and as a detail of its virtual cluster. The cloud administrator selects which resources in BMC Server Automation to onboard to the cloud.

Compute resources are grouped into compute resource pools based on administrative policies. For example, compute resources might be pooled by the service levels (such as Platinum, Gold, and Silver) or tenants they are intended to support. Compute resources can be provisioned only after they are added to a compute resource pool.

Compute resource pools allow for easier and faster management of the resources in those pools. They also enable cloud administrators to see the overall capacity of the resources in a pool, and whether the pool is suffering from performance degradation, such as when a virtual machine is down. For example, resource pools enable the cloud administrator to see available Platinum, Gold, and Silver storage capacity, whether a DMZ or VLAN exists already, and how much RAM is available in the pool. This capacity information can be sorted by physical and logical groupings, end user company, and end user account. For more information about compute resource pools, see Editing and removing resources.

Cloud administrators can create the following types of compute resource pools:

• Physical server — A pool of physical servers used for provisioning workloads or parts of workloads to physical servers. Because physical servers are attached to network pods, physical servers in a pod must be in the same compute resource pool.
• Virtual cluster — A pool of virtual clusters. Virtual cluster pools can span virtualCenters of XenServer clusters. However, all compute resources in a virtual cluster pool must be from the same vendor (VMware or Citrix Xen). A virtual cluster pool cannot include a mix of VMware and Citrix Xen compute resources. All resources in a virtual cluster pool must also share the same architecture (such as x86 or 64-bit).
• Virtual host — A pool of virtual hosts, such as VMware or ESX. Virtual hosts in the same pool must be from the same vendor and share the same architecture.
• Virtual resource pool — A pool with one or more VMware or Citrix Xen virtual resource pools. Virtual resource pools in the same pool must be from the same vendor and share the same architecture.
• Virtual disk repository — A pool of either VMware datastores or Citrix Xen storage repositories, used for provisioning virtual disks for workloads. Resources in the same virtual disk repository pool must be from the same vendor.

After the cloud administrator creates network containers, compute resource pools are mapped to network containers. In this way, network resources provide the organization for compute resource pools. Multiple compute resource pools can be mapped to individual network containers. For example, a cloud administrator might map some higher-performing resource pools to a Production Environment network container, and lower-performing resource pools to a Pre-production Environment network container, as shown in the following diagram:

Example of compute resource pool and network container mapping

Cloud administrators can tag compute resource pools to automate placement decisions. For more information about tags, see Policy management overview.