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
DRS Cluster Requirements
Hosts that are added to a DRS cluster must meet certain requirements to use cluster features successfully.
Shared Storage Requirements
A DRS cluster has certain shared storage requirements.
Ensure that the managed hosts use shared storage. Shared storage is typically on a SAN, but can also be
implemented using NAS shared storage.
See the vSphere Storage documentation for information about other shared storage.
Shared VMFS Volume Requirements
A DRS cluster has certain shared VMFS volume requirements.
Congure all managed hosts to use shared VMFS volumes.
n
Place the disks of all virtual machines on VMFS volumes that are accessible by source and destination
hosts.
n
Ensure the VMFS volume is suciently large to store all virtual disks for your virtual machines.
n
Ensure all VMFS volumes on source and destination hosts use volume names, and all virtual machines
use those volume names for specifying the virtual disks.
N Virtual machine swap les also need to be on a VMFS accessible to source and destination hosts (just
like .vmdk virtual disk les). This requirement does not apply if all source and destination hosts are ESX
Server 3.5 or higher and using host-local swap. In that case, vMotion with swap les on unshared storage is
supported. Swap les are placed on a VMFS by default, but administrators might override the le location
using advanced virtual machine conguration options.
Processor Compatibility Requirements
A DRS cluster has certain processor compatibility requirements.
To avoid limiting the capabilities of DRS, you should maximize the processor compatibility of source and
destination hosts in the cluster.
vMotion transfers the running architectural state of a virtual machine between underlying ESXi hosts.
vMotion compatibility means that the processors of the destination host must be able to resume execution
using the equivalent instructions where the processors of the source host were suspended. Processor clock
speeds and cache sizes might vary, but processors must come from the same vendor class (Intel versus
AMD) and the same processor family to be compatible for migration with vMotion.
Processor families are dened by the processor vendors. You can distinguish dierent processor versions
within the same family by comparing the processors’ model, stepping level, and extended features.
Sometimes, processor vendors have introduced signicant architectural changes within the same processor
family (such as 64-bit extensions and SSE3). VMware identies these exceptions if it cannot guarantee
successful migration with vMotion.
vCenter Server provides features that help ensure that virtual machines migrated with vMotion meet
processor compatibility requirements. These features include:
n
Enhanced vMotion Compatibility (EVC) – You can use EVC to help ensure vMotion compatibility for
the hosts in a cluster. EVC ensures that all hosts in a cluster present the same CPU feature set to virtual
machines, even if the actual CPUs on the hosts dier. This prevents migrations with vMotion from
failing due to incompatible CPUs.
Chapter 10 Creating a DRS Cluster
VMware, Inc. 67