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
Why Use Resource Pools?
Resource pools allow you to delegate control over resources of a host (or a cluster), but the benefits are
evident when you use resource pools to compartmentalize all resources in a cluster. Create multiple
resource pools as direct children of the host or cluster and configure them. You can then delegate control
over the resource pools to other individuals or organizations.
Using resource pools can result in the following benefits.
n
Flexible hierarchical organization—Add, remove, or reorganize resource pools or change resource
allocations as needed.
n
Isolation between pools, sharing within pools—Top-level administrators can make a pool of resources
available to a department-level administrator. Allocation changes that are internal to one departmental
resource pool do not unfairly affect other unrelated resource pools.
n
Access control and delegation—When a top-level administrator makes a resource pool available to a
department-level administrator, that administrator can then perform all virtual machine creation and
management within the boundaries of the resources to which the resource pool is entitled by the
current shares, reservation, and limit settings. Delegation is usually done in conjunction with
permissions settings.
n
Separation of resources from hardware—If you are using clusters enabled for DRS, the resources of all
hosts are always assigned to the cluster. That means administrators can perform resource management
independently of the actual hosts that contribute to the resources. If you replace three 2GB hosts with
two 3GB hosts, you do not need to make changes to your resource allocations.
This separation allows administrators to think more about aggregate computing capacity and less about
individual hosts.
n
Management of sets of virtual machines running a multitier service— Group virtual machines for a
multitier service in a resource pool. You do not need to set resources on each virtual machine. Instead,
you can control the aggregate allocation of resources to the set of virtual machines by changing settings
on their enclosing resource pool.
For example, assume a host has a number of virtual machines. The marketing department uses three of the
virtual machines and the QA department uses two virtual machines. Because the QA department needs
larger amounts of CPU and memory, the administrator creates one resource pool for each group. The
administrator sets CPU Shares to High for the QA department pool and to Normal for the Marketing
department pool so that the QA department users can run automated tests. The second resource pool with
fewer CPU and memory resources is sufficient for the lighter load of the marketing staff. Whenever the QA
department is not fully using its allocation, the marketing department can use the available resources.
The numbers in the following figure show the effective allocations to the resource pools.
Figure 9‑2. Allocating Resources to Resource Pools
VM-QA 1 VM-QA 2
6GHz, 3GB
4GHz, 2GB 2GHz, 1GB
RP-QA
VM-Marketing 1 VM-Marketing 2 VM-Marketing 3
RP-
Marketing
host
vSphere Resource Management
56 VMware, Inc.