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
Table 11‑2. vCenter Server Events (Continued)
Event Type Event Name
Exiting Standby mode (about to power on the host)
DrsExitingStandbyModeEvent
Successfully exited Standby mode (power on succeeded)
DrsExitedStandbyModeEvent
For more information about creating and editing alarms, see the vSphere Monitoring and Performance
documentation.
If you use monitoring software other than vCenter Server, and that software triggers alarms when physical
hosts are powered o unexpectedly, you might have a situation where false alarms are generated when
vSphere DPM places a host into standby mode. If you do not want to receive such alarms, work with your
vendor to deploy a version of the monitoring software that is integrated with vCenter Server. You could also
use vCenter Server itself as your monitoring solution, because starting with vSphere 4.x, it is inherently
aware of vSphere DPM and does not trigger these false alarms.
Using DRS Affinity Rules
You can control the placement of virtual machines on hosts within a cluster by using anity rules.
You can create two types of rules.
n
Used to specify anity or anti-anity between a group of virtual machines and a group of hosts. An
anity rule species that the members of a selected virtual machine DRS group can or must run on the
members of a specic host DRS group. An anti-anity rule species that the members of a selected
virtual machine DRS group cannot run on the members of a specic host DRS group.
See “VM-Host Anity Rules,” on page 88 for information about creating and using this type of rule.
n
Used to specify anity or anti-anity between individual virtual machines. A rule specifying anity
causes DRS to try to keep the specied virtual machines together on the same host, for example, for
performance reasons. With an anti-anity rule, DRS tries to keep the specied virtual machines apart,
for example, so that when a problem occurs with one host, you do not lose both virtual machines.
See “VM-VM Anity Rules,” on page 87 for information about creating and using this type of rule.
When you add or edit an anity rule, and the cluster's current state is in violation of the rule, the system
continues to operate and tries to correct the violation. For manual and partially automated DRS clusters,
migration recommendations based on rule fulllment and load balancing are presented for approval. You
are not required to fulll the rules, but the corresponding recommendations remain until the rules are
fullled.
To check whether any enabled anity rules are being violated and cannot be corrected by DRS, select the
cluster's DRS tab and click Faults. Any rule currently being violated has a corresponding fault on this page.
Read the fault to determine why DRS is not able to satisfy the particular rule. Rules violations also produce
a log event.
N VM-VM and VM-Host anity rules are dierent from an individual host’s CPU anity rules.
Create a Host DRS Group
A VM-Host anity rule establishes an anity (or anti-anity) relationship between a virtual machine DRS
group with a host DRS group. You must create both of these groups before you can create a rule that links
them.
Procedure
1 Browse to the cluster in the vSphere Web Client navigator.
2 Click the tab.
vSphere Resource Management
86 VMware, Inc.