6.0.1
Table Of Contents
- vSphere Resource Management
- Contents
- About vSphere Resource Management
- Updated Information
- Getting Started with Resource Management
- Configuring Resource Allocation Settings
- CPU Virtualization Basics
- Administering CPU Resources
- Memory Virtualization Basics
- Administering Memory Resources
- View Graphics Information
- 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
CPU Virtualization Basics 3
CPU virtualization emphasizes performance and runs directly on the processor whenever possible. The
underlying physical resources are used whenever possible and the virtualization layer runs instructions
only as needed to make virtual machines operate as if they were running directly on a physical machine.
CPU virtualization is not the same thing as emulation. ESXi does not use emulation to run virtual CPUs.
With emulation, all operations are run in software by an emulator. A software emulator allows programs to
run on a computer system other than the one for which they were originally written. The emulator does this
by emulating, or reproducing, the original computer’s behavior by accepting the same data or inputs and
achieving the same results. Emulation provides portability and runs software designed for one platform
across several platforms.
When CPU resources are overcommitted, the ESXi host time-slices the physical processors across all virtual
machines so each virtual machine runs as if it has its specified number of virtual processors. When an ESXi
host runs multiple virtual machines, it allocates to each virtual machine a share of the physical resources.
With the default resource allocation settings, all virtual machines associated with the same host receive an
equal share of CPU per virtual CPU. This means that a single-processor virtual machines is assigned only
half of the resources of a dual-processor virtual machine.
This chapter includes the following topics:
n
“Software-Based CPU Virtualization,” on page 19
n
“Hardware-Assisted CPU Virtualization,” on page 20
n
“Virtualization and Processor-Specific Behavior,” on page 20
n
“Performance Implications of CPU Virtualization,” on page 20
Software-Based CPU Virtualization
With software-based CPU virtualization, the guest application code runs directly on the processor, while the
guest privileged code is translated and the translated code executes on the processor.
The translated code is slightly larger and usually executes more slowly than the native version. As a result,
guest programs, which have a small privileged code component, run with speeds very close to native.
Programs with a significant privileged code component, such as system calls, traps, or page table updates
can run slower in the virtualized environment.
VMware, Inc.
19