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
virtual machine often consumes less memory than it might when running on physical machines. As a result,
higher levels of overcommitment can be supported eciently. The amount of memory saved by memory
sharing depends on whether the workload consists of nearly identical machines which might free up more
memory. A more diverse workload might result in a lower percentage of memory savings.
N Due to security concerns, inter-virtual machine transparent page sharing is disabled by default and
page sharing is being restricted to intra-virtual machine memory sharing. Page sharing does not occur
across virtual machines and only occurs inside a virtual machine. See “Sharing Memory Across Virtual
Machines,” on page 40 for more information.
Types of Memory Virtualization
There are two types of memory virtualization: Software-based and hardware-assisted memory
virtualization.
Because of the extra level of memory mapping introduced by virtualization, ESXi can eectively manage
memory across all virtual machines. Some of the physical memory of a virtual machine might be mapped to
shared pages or to pages that are unmapped, or swapped out.
A host performs virtual memory management without the knowledge of the guest operating system and
without interfering with the guest operating system’s own memory management subsystem.
The VMM for each virtual machine maintains a mapping from the guest operating system's physical
memory pages to the physical memory pages on the underlying machine. (VMware refers to the underlying
host physical pages as “machine” pages and the guest operating system’s physical pages as “physical”
pages.)
Each virtual machine sees a contiguous, zero-based, addressable physical memory space. The underlying
machine memory on the server used by each virtual machine is not necessarily contiguous.
For both software-based and hardware-assisted memory virtualization, the guest virtual to guest physical
addresses are managed by the guest operating system. The hypervisor is only responsible for translating the
guest physical addresses to machine addresses. Software-based memory virtualization combines the guest's
virtual to machine addresses in software and saves them in the shadow page tables managed by the
hypervisor. Hardware-assisted memory virtualization utilizes the hardware facility to generate the
combined mappings with the guest's page tables and the nested page tables maintained by the hypervisor.
The diagram illustrates the ESXi implementation of memory virtualization.
Figure 5‑1. ESXi Memory Mapping
virtual machine
1
guest virtual memory
guest physical memory
machine memory
a b
a
a b b c
b
c b
b c
virtual machine
2
n
The boxes represent pages, and the arrows show the dierent memory mappings.
n
The arrows from guest virtual memory to guest physical memory show the mapping maintained by the
page tables in the guest operating system. (The mapping from virtual memory to linear memory for
x86-architecture processors is not shown.)
n
The arrows from guest physical memory to machine memory show the mapping maintained by the
VMM.
Chapter 5 Memory Virtualization Basics
VMware, Inc. 29