eG Monitoring
 

Measures reported by EsxResourcePoolTest

Resource pools can be used to hierarchically partition available CPU and memory resources. Each standalone host has an (invisible) root resource pool that groups the resources of that host. The root resource pool is not displayed because the resources of the host and the root resource pool are always the same. If you do not create child resource pools, only the root resource pools exist. Users can create child resource pools of the root resource pool or of any user-created child resource pool. Each child resource pool owns some of the parent's resources and can, in turn, have a hierarchy of child resource pools to represent successively smaller units of computational capability. A resource pool can contain child resource pools, virtual machines, or both. You can therefore create a hierarchy of shared resources. The resource pools at a higher level are called parent resource pools. Resource pools and virtual machines that are at the same level are called siblings.

vApp, is a logical entity comprising one or more virtual machines, which uses the industry standard Open Virtualization Format to specify and encapsulate all components of a multi-tier application as well as the operational policies and service levels associated with it. Just like the UPC bar code contains all information about a product, the vApp gives application owners a standard way to describe operational policies for an application which the cloud OS can automatically interpret and execute. vApps can comprise of any applications running on any OS, and provide a mechanism for customers to move their applications between internal clouds or external clouds with still the same service levels.

This test monitors the amount of the physical server's resources that each resource pool/vApp on an ESX/vSphere server is taking up. To distinguish between vApps and resource pools, the eG monitoring console tags every discovered vApp as [vApp].

Measurement Description Measurement Unit Interpretation
Child_resource_pools The total number of child resource pools under this resource pool Number  
Total_virtual_machines The number of virtual machines that were directly assigned to this resource pool Number  
Vms_powered_on The number of virtual machines under this resource pool that is currently powered on Number If the value of this measure is equal to the value of the Total_virtual_machines measure, it indicates that all VMs in the pool are in a powered-on state. If the values do not match, it indicates that one/more VMs are currently in a powered-off state.
Cpu_usage The CPU usage of the resource pool in Mhz Mhz The percent CPU usage measure serves as an effective indicator of how resource-intensive a particular resource pool is on a specific ESX server. However, for performing capacity planning or what-if analysis, the CPU usage of a pool measured in absolute terms would be more useful. For instance, the physical CPU usage of a pool could be 30% on a particular ESX server - this means that the resource pool is consuming 30% of the total physical CPU capacity of that ESX server. If you are planning to migrate the resource pool to another ESX server, then it would be unwise to assume that the pool will only consume 30% of CPU on the other ESX server as well, as the percentage will vary depending upon the physical CPU resources that are available to the other ESX server. The absolute measure however will remain unchanged across ESX server. Therefore, to decide which ESX server a VM/resource pool is to be moved to, and to analyze the impact of this movement on the CPU resources of the new ESX host, you would require an absolute measure of CPU usage.
Physical_cpu_used The percentage of physical CPU resources used from this pool Percent A high value of this measure could indicate excessive CPU usage by the child resource pools/virtual machines configured under this resource pool. By comparing the value of this measure across resource pools, you can quickly identify that resource pool which is draining the CPU resources of the ESX host.
Cpu_reservation The amount of CPU resources that is guaranteed available to the resource pool Mhz Typically, the Reservation setting for a resource pool specifies the minimum acceptable amount of CPU or memory - not the amount you would like to have available. Follow the guidelines mentioned below to define the Reservation setting:
  • Do not set the Reservation too high. A very high reservation can limit the number of virtual machines you can power on in a resource pool.
  • Always leave some headroom while reserving resource. Do not commit all resources. As you move closer to fully reserving all capacity in the system, it becomes increasingly difficult to make changes to reservations and to the resource pool hierarchy without violating admission control.
  • If you expect frequent changes to the total available resources, use Shares, not Reservation, to allocate resources fairly across resource pools.
Cpu_reservation_used The total amount of CPU resources that have been used to satisfy the reservation requirements of all descendants of this resource pool Mhz CPU resources are typically reserved for powered-on virtual machines in a resource pool only. Virtual machines that are not currently running do not use any CPU resources. Reserved resources are not wasted if they are not used. If the utilization is less than the reservation, the resources can be utilized by other running virtual machines.
Cpu_unreserved The total amount of resources available to satisfy a reservation for a child resource pool Mhz In the undercommitted state, this value is limited by the capacity at the root node. In the overcommitted case, this could be higher since we do not perform the dynamic capacity checks. Consider a resource pool with reservation=2GHz that istotally idle. It has 2GHz reserved, but it is not actually using any of its reservation. In such a case:
  • Other resource pools cannot reserve these 2GHz.
  • Other resource can use these 2GHz, that is, idle CPU reservations are not wasted.
Cpu_allocation_used The percentage of allocated CPU resources that are being used by this resource pool Percent A high value of this measure indicates that one/more VMs in the pool are consuming the allocated CPU resources excessively.
Cpu_limit The limit beyond which this resource pool should not use CPU resources, even if there are resources available Mhz If the Unlimited flag is enabled for a resource pool, then this measure will report the value Unlimited. This setting helps avoid wastage of idle resources.
Memory_used The amount of memory used by this resource pool MB  
Memory_reservation The amount of memory resources that is guaranteed available to the resource pool. MB Typically, the Reservation setting for a resource pool specifies the minimum acceptable amount of CPU or memory - not the amount you would like to have available. Follow the guidelines mentioned below to define the Reservation setting:
  • Do not set the Reservation too high. A very high reservation can limit the number of virtual machines you can power on in a resource pool.
  • Always leave some headroom while reserving resource. Do not commit all resources. As you move closer to fully reserving all capacity in the system, it becomes increasingly difficult to make changes to reservations and to the resource pool hierarchy without violating admission control.
  • If you expect frequent changes to the total available resources, use Shares, not Reservation, to allocate resources fairly across resource pools.
Memory_reservation_used The total amount of CPU resources that have been used to satisfy the reservation requirements of all descendants of this resource pool MB Memory resources are typically reserved for powered-on virtual machines in a resource pool only. Virtual machines that are not currently running do not use any memory resources. Reserved resources are not wasted if they are not used. If the utilization is less than the reservation, the resources can be utilized by other running virtual machines.
Memory_unreserved The total amount of resources available to satisfy a reservation for a child resource pool MB In the undercommitted state, this value is limited by the capacity at the root node. In the overcommitted case, this could be higher since we do not perform the dynamic capacity checks. If the resource pool does not use the reserved memory, then remember the following:
  • Other resource pools cannot reserve these memory resources
  • Other resource pools can use these memory resources, that is, idle memory reservations are not wasted
Memory_limit The limit beyond which this resource pool should not use memory resources, even if there are resources available MB If the Unlimited flag is enabled for a resource pool, then this measure will report the value Unlimited. This setting helps avoid wastage of idle resources.
Active_memory The amount of memory resources actively used from this pool MB High memory consumption by a resource pool, besides eroding the physical memory resources of the host, can also impact the memory allocations to other resource pools/virtual machines; the lack of adequate memory to a VM can significantly strain its performance.
Active_memory_used The percentage of total configured or available memory in this pool Percent
Zero_memory The amount of memory that is zeroed out MB  
Swapped_memory The amount of memory that is swapped MB ESX Server hosts use swapping to forcibly reclaim memory from a virtual machine when no vmmemctl driver is available because the vmmemctl driver:
  • Was never installed
  • Has been explicitly disabled
  • Is not running (for example, while the guest operating system is booting
  • Is temporarily unable to reclaim memory quickly enough to satisfy current system demands

Standard demand-paging techniques swap pages back in when the virtual machine needs them.Swap space must be reserved on disk for any unreserved virtual machine memory. This swap reservation is required to ensure the system is able to preserve virtual machine memory under any circumstances. In practice, only a small fraction of the swap space may actually be used.Typically, swap space usage for each VM should be low. Since access from RAM is much faster than access from physical disk, excessive usage of swap memory will slow down the performance of a VM. Watch for VMs that are seeing higher swap usage and more swap reads and writes.

Memory_overhead The memory overhead incurred by this resource pool MB SX Server virtual machines can incur two kinds of memory overhead:
  • The additional time to access memory within a virtual machine.
  • The extra space needed by the ESX Server host for its own code and data structures, beyond the memory allocated to each virtual machine.

The ESX server's memory virtualization ensures that the time overhead to memory accesses is minimal. The memory space overhead, on the other hand, is composed of two other components:

  • A fixed system-wide overhead for the service console (in the case of ESX 3/3.5) and the VMkernel.
  • Additional overhead for each virtual machine

In addition, the space reserved for the virtual machine frame buffer and various virtualization data structures, also add to the memory overhead. Addition of more virtual CPUs, allocation of more memory to the guests, and choosing to configure 32-bit guest operating systems instead of 64-bit ones, can go a long way in reducing this overhead. The ESX server also provides optimizations such as memory sharing to save up memory.

Balloon_memory The total amount of physical memory currently reclaimed from this guest using the vmmemctl modules MB The vmmectl driver that is installed on a virtual machine, emulates an increase or decrease inmemory pressure on the guest operating system; this way, it forces the guest OS to placememory pages into its local swap file. This driver differs from theVMware swap file method as it forces the operating system to determinewhat memory it wishes to page. Once the memory is pagedlocally on the guest operating system, the free physical pages of memory may be reallocated to other guests. As the ESX hosts sees thatmemory demand has been reduced, it will instruct vmmemctl to"deflate" the balloon and reduce pressure on the guest OS to pagememory. The maximum amount of memory that can be reclaimed from a guest may be configured by modifying the "sched.mem.maxmemctl" advanced option.If the memory reclaimed from a guest (i.e., the value of this measure) is very low, it indicates excessive memory usage by the guest. Under such circumstances, you might want to consider allocating more memory to the guest.
Memory_granted The amount of memory that the Vmkernel has granted to the virtual machine MB  
Shared_memory The current amount of shared guest operating system memory MB