6.5.1
Table Of Contents
- vSphere Resource Management
- Contents
- About vSphere Resource Management
- Getting Started with Resource Management
- Configuring Resource Allocation Settings
- CPU Virtualization Basics
- Administering CPU Resources
- Memory Virtualization Basics
- Administering Memory Resources
- Configuring Virtual Graphics
- Managing Storage I/O Resources
- Managing Resource Pools
- Creating a DRS Cluster
- Using DRS Clusters to Manage Resources
- Creating a Datastore Cluster
- Initial Placement and Ongoing Balancing
- Storage Migration Recommendations
- Create a Datastore Cluster
- Enable and Disable Storage DRS
- Set the Automation Level for Datastore Clusters
- Setting the Aggressiveness Level for Storage DRS
- Datastore Cluster Requirements
- Adding and Removing Datastores from a Datastore Cluster
- Using Datastore Clusters to Manage Storage Resources
- Using NUMA Systems with ESXi
- Advanced Attributes
- Fault Definitions
- Virtual Machine is Pinned
- Virtual Machine not Compatible with any Host
- VM/VM DRS Rule Violated when Moving to another Host
- Host Incompatible with Virtual Machine
- Host Has Virtual Machine That Violates VM/VM DRS Rules
- Host has Insufficient Capacity for Virtual Machine
- Host in Incorrect State
- Host Has Insufficient Number of Physical CPUs for Virtual Machine
- Host has Insufficient Capacity for Each Virtual Machine CPU
- The Virtual Machine Is in vMotion
- No Active Host in Cluster
- Insufficient Resources
- Insufficient Resources to Satisfy Configured Failover Level for HA
- No Compatible Hard Affinity Host
- No Compatible Soft Affinity Host
- Soft Rule Violation Correction Disallowed
- Soft Rule Violation Correction Impact
- DRS Troubleshooting Information
- Cluster Problems
- Load Imbalance on Cluster
- Cluster is Yellow
- Cluster is Red Because of Inconsistent Resource Pool
- Cluster Is Red Because Failover Capacity Is Violated
- No Hosts are Powered Off When Total Cluster Load is Low
- Hosts Are Powered-off When Total Cluster Load Is High
- DRS Seldom or Never Performs vMotion Migrations
- Host Problems
- DRS Recommends Host Be Powered on to Increase Capacity When Total Cluster Load Is Low
- Total Cluster Load Is High
- Total Cluster Load Is Low
- DRS Does Not Evacuate a Host Requested to Enter Maintenance or Standby Mode
- DRS Does Not Move Any Virtual Machines onto a Host
- DRS Does Not Move Any Virtual Machines from a Host
- Virtual Machine Problems
- Cluster Problems
- Index
n
Working set size — ESXi hosts estimate the working set for a virtual machine by monitoring memory
activity over successive periods of virtual machine execution time. Estimates are smoothed over several
time periods using techniques that respond rapidly to increases in working set size and more slowly to
decreases in working set size.
This approach ensures that a virtual machine from which idle memory is reclaimed can ramp up
quickly to its full share-based allocation when it starts using its memory more actively.
Memory activity is monitored to estimate the working set sizes for a default period of 60 seconds. To
modify this default , adjust the Mem.SamplePeriod advanced seing. See “Set Advanced Host
Aributes,” on page 115.
Memory Tax for Idle Virtual Machines
If a virtual machine is not actively using all of its currently allocated memory, ESXi charges more for idle
memory than for memory that is in use. This is done to help prevent virtual machines from hoarding idle
memory.
The idle memory tax is applied in a progressive fashion. The eective tax rate increases as the ratio of idle
memory to active memory for the virtual machine rises. (In earlier versions of ESXi that did not support
hierarchical resource pools, all idle memory for a virtual machine was taxed equally.)
You can modify the idle memory tax rate with the Mem.IdleTax option. Use this option, together with the
Mem.SamplePeriod advanced aribute, to control how the system determines target memory allocations for
virtual machines. See “Set Advanced Host Aributes,” on page 115.
N In most cases, changes to Mem.IdleTax are not necessary nor appropriate.
VMX Swap Files
Virtual machine executable (VMX) swap les allow the host to greatly reduce the amount of overhead
memory reserved for the VMX process.
N VMX swap les are not related to the swap to host swap cache feature or to regular host-level swap
les.
ESXi reserves memory per virtual machine for a variety of purposes. Memory for the needs of certain
components, such as the virtual machine monitor (VMM) and virtual devices, is fully reserved when a
virtual machine is powered on. However, some of the overhead memory that is reserved for the VMX
process can be swapped. The VMX swap feature reduces the VMX memory reservation signicantly (for
example, from about 50MB or more per virtual machine to about 10MB per virtual machine). This allows the
remaining memory to be swapped out when host memory is overcommied, reducing overhead memory
reservation for each virtual machine.
The host creates VMX swap les automatically, provided there is sucient free disk space at the time a
virtual machine is powered on.
Memory Reclamation
ESXi hosts can reclaim memory from virtual machines.
A host allocates the amount of memory specied by a reservation directly to a virtual machine. Anything
beyond the reservation is allocated using the host’s physical resources or, when physical resources are not
available, handled using special techniques such as ballooning or swapping. Hosts can use two techniques
for dynamically expanding or contracting the amount of memory allocated to virtual machines.
n
ESXi systems use a memory balloon driver (vmmemctl), loaded into the guest operating system running
in a virtual machine. See “Memory Balloon Driver,” on page 36.
Chapter 6 Administering Memory Resources
VMware, Inc. 35