State	Value
Off	0
On	1
Suspended	2
Unknown	3
Standby	4
Shuttingdown	5
Resetting	6
Stuck	7

Note:

By default, this measure reports one of the States listed in the table above. The graph of this measure however will represent the VM status using the numeric equivalents - ‘0’ to ‘7’.

Even though the VM is ready to run, if it is prevented from running owing to a probable limit violation, then the value of this measure will not be included in the value of the VM CPU ready measure.

A high value for this metric indicates that the VM has been trying to get additional CPU resources but has not been able to do so because the CPU usage for this VM or its resource pool (if it is a part of a resource pool) has reached the allocated limit.

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

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.

• 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

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

This measure reveals the disk capacity of a VM, regardless of its on/off state. A quick comparison of the capacity across VMs can enable administrators to accurately identify the VM that is taking up maximum disk space.

The numeric values that correspond to the measure values discussed above are listed in the table below:

Note:

By default, this measure reports the values Yes or No only to indicate whether the memory is configured correctly or not. The graph of this measure however, will represent the memory state using the numeric equivalents - ‘0’ or ‘1’.

Measure Value	Description
Connected	The vCenter server has access to the virtual machine.
Disconnected	The vCenter server is currently disconnected from the virtual machine, since its host is disconnected.
Inaccessible	One or more of the virtual machine configuration files are inaccessible. For example, this can be due to transient disk failures. In this case, no configuration can be returned for a virtual machine.
Invalid	The virtual machine configuration format is invalid. Thus, it is accessible on disk, but corrupted in a way that does not allow the server to read the content. In this case, no configuration can be returned for a virtual machine.
Orphaned	The virtual machine is no longer registered on the host it is associated with. For example, a virtual machine that is unregistered or deleted directly on a host managed by vCenter shows up in this state.

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

Numeric Value	Measure Value
0	Orphaned
1	Connected
2	Disconnected
3	Inaccessible
4	Invalid

Note:

By default, this measure reports the Measure Values to indicate the connection status. In the graph of this measure however, status will be represented using the numeric equivalents - 0 through 4.

The value of this measure indicates the amount of memory consumed by the compressed pages in the compression cache of a VM. Ideally, this value should be much less than the maximum size upto which the compression cache has been configured to grow. If the value of this measure is close or equal to the maximum size configuration of the compression cache, then it means that the compression cache is filling up rapidly, and will soon run out of memory. When this happens, a lot of replaced compressed pages will be decompressed and swapped out to accommodate more compressed pages in the cache. Any following swapins of those pages will hurt VM performance. This can happen if the maximum size of the compression cache is set too low.

At the same time, a very large compression cache may also waste VM memory and unnecessarily create host memory pressure, especially when most compressed pages would not be touched in the future.

By prudently setting the maximum size of the compression cache, you can ensure optimal usage of the cache and can avoid the eventualities discussed above.

VMware DRS dynamically balances computing capacity across a collection of hardware resources aggregated into logical resource pools, continuously monitoring utilization across resource pools and intelligently allocating available resources among the virtual machines based on pre-defined rules that reflect business needs and changing priorities. When a virtual machine experiences an increased load, VMware DRS automatically allocates additional resources by redistributing virtual machines among the physical servers in the resource pool.

By comparing the value of this measure across VMs, you can identify those VMs that DRS has marked as CPU-intensive, and has hence allocated more CPU resources.

VMware DRS dynamically balances computing capacity across a collection a logical resource pools, continuously monitoring utilization across resource pools and intelligently allocating available resources among the virtual machines based on pre-defined rules that reflect business needs and changing priorities. When a virtual machine experiences an increased load, VMware DRS automatically allocates additional resources by redistributing virtual machines among the physical servers in the resource pool.

By comparing the value of this measure across VMs, you can identify those VMs that DRS has marked as memory-intensive, and has hence allocated more memory resources.

Ideally, the value of this measure should be low. Any increase in the value of this measure for a VM, will automatically increase the value of the Physical memory consumed measure of that VM. This is because:

Private_mem + Memory_overhead = Memory_consumed

This value is only set if memory allocation level is set to custom.

If the memory pages are swapped out to the host cache at a high rate - i.e., if the value of this measure is consistently high - check the amount of free physical memory on the host. A free memory value of 6% or less indicates that the host requires more memory resources.

The host cache is made up of files on a low-latency disk that ESXi uses as a write back cache for virtual machine swap files. The cache is shared by all virtual machines running on the host.

When there is severe memory pressure and the hypervisor needs to swap memory pages to disk it will swap to the host cache on the SSD drive instead. If the value of this measure rises consistently, it indicates that the VM is swapping many memory pages to the host cache. Also, If the value of this measure is equal to the space allocated to the host cache, it means that the memory pages swapped by that VM have completely filled the host cache. Such a VM can be marked as a memory-starved VM.

Under such circumstances, these memory pages will need to be copied to the regular .vswp file. This is not a recommended practice as it will decrease performance for your VMs as these pages more than likely at some point will need to be swapped in. To avoid this therefore, you may want to allocate more host cache space to the VM. You may also want to consider allocating more memory to that VM, so that the VM does not have to resort to swapping memory (to host cache).