Selecting the right containers to include in capacity management depends greatly on the adapter (source of the data), the target environment, and any organizational policies. Continuing on from the current focus of a vSphere Compute Cluster, since it is the most common object, administrators would be required to perform capacity management reporting. We will quickly cover some common recommendations for what containers we enable on our generic production vSphere Cluster policy:

• CPU (Enabled): CPU should generally be enabled when assessing capacity for virtual machines, hosts, and clusters. CPU is a configured container and is probably the most accurate container used on vSphere objects. As a general rule, when administrators are sizing vSphere clusters or deciding what type of new hardware should be procured, CPU and memory are usually at the top of the list. This is because CPU and memory are the two most common constraining factors of capacity in virtualized environments.
• Memory (Enabled): In similar circumstances to CPU, memory is usually always enabled and generally a critical container for capacity management of virtualized environments. Memory is also a configured container, however, the accuracy of memory demand (which will be discussed shortly) varies based on workload and right-sizing. In most production server virtualization environments, memory is the constraining resource for capacity management. It is also often the most wasted resource, and as such is critical for capacity management reporting.
• Network I/O (Disabled): Due to some of the drawbacks of observed containers and the fact that most administrators will use a separate solution pack for network and storage, these containers are commonly disabled for capacity analysis in many environments. It is also rare that Network I/O is a constraining factor in most environments since the common adoption of 10 GB Ethernet.
• Datastore I/O (Disabled): In similar circumstances to Network I/O, Datastore I/O is commonly disabled due to the constraints of observed containers. However, unlike Network I/O, Datastore I/O and storage performance, in general, is a highly important area of capacity management for vitalized environments. As such, it is recommended that an administrator is keeping an eye on the performance capacity of their storage (not just the storage capacity), but this is commonly performed using a vendor-provided solution pack.
• Disk Space (Situational): The use of disk space as a capacity management container depends on your target environment and procedures. As a general rule, disk space can be extremely useful as a capacity management metric if your storage is pre-provisioned or you are using thin provisioning at the VMDK level. As such, there are some situations where you may or may not enable disk space.

We would recommend enabling disk space when:

• All storage from the physical array is pre-provisioned to the vSphere environment
• Using Datastore-level thin provisioning (thin VMDKs)
• Using VSAN or local storage

We would recommend another solution when:

• Storage capacity is managed at the array level and LUNs (Datastores) are provisioned on demand
• Array-level thin provisioning is being used, such as FAST VP, and your environment has targeted overallocation ratios at the array level

As mentioned previously, in the case where storage is being provisioned on demand, or array-based thin provisioning is being used with over-commitment, it is recommended that a vendor-provided solution pack be used to pull in capacity metrics from the array directly.

• vSphere configuration limits (Enabled): The use of vSphere configuration limits as part of capacity management is a new feature of vRealize Operations 6.0. In most cases, it is unlikely that there will be a concern, however they still provide useful information, so it is recommended to leave them enabled. vSphere configuration limits for capacity management can be particularly useful when looking at the ESXi host level, for example.