The numeric values that correspond to these measures are as follows:

State	Value
Unknown	0
Normal	1
Overcommitted	2
Inconsistent	3

The detailed diagnosis of this measure, if enabled, reveals the names and CPU usage of each VM in this pool, thus revealing which VM is CPU-intensive.

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.

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.

• Other resource pools cannot reserve these 2GHz.
• Other resource can use these 2GHz, that is, idle CPU reservations are not wasted.

This is typically used to ensure a consistent performance of virtual machines / resource pools independent of available resources. If set to -1, then there is no fixed limit on resource usage (only bounded by available resources and shares).

• 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.

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.

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.

• Other resource pools cannot reserve these memory resources
• Other resource pools can use these memory resources, that is, idle memory reservations are not wasted

This is typically used to ensure a consistent performance of virtual machines / resource pools independent of available resources. If set to -1, then there is no fixed limit on resource usage (only bounded by available resources and shares).

• 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.

• 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.

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.