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
About Virtual Machine Storage Policies
Virtual machine storage policies are essential to virtual machine provisioning. The policies control which
type of storage is provided for the virtual machine, how the virtual machine is placed within the storage,
and which data services are oered for the virtual machine.
vSphere includes default storage policies. However, you can dene and assign new policies.
You use the VM Storage Policies interface to create a storage policy. When you dene the policy, you specify
various storage requirements for applications that run on virtual machines. You can also use storage policies
to request specic data services, such as caching or replication, for virtual disks.
You apply the storage policy when you create, clone, or migrate the virtual machine. After you apply the
storage policy, the Storage Policy Based Management (SPBM) mechanism places the virtual machine in a
matching datastore and, in certain storage environments, determines how the virtual machine storage
objects are provisioned and allocated within the storage resource to guarantee the required level of service.
The SPBM also enables requested data services for the virtual machine. vCenter Server monitors policy
compliance and sends an alert if the virtual machine is in breach of the assigned storage policy.
See vSphere Storage for more information.
About I/O Filters
I/O lters that are associated with virtual disks gain direct access to the virtual machine I/O path regardless
of the underlying storage topology.
VMware oers certain categories of I/O lters. In addition, the I/O lters can be created by third-party
vendors. Typically, they are distributed as packages that provide an installer to deploy lter components on
vCenter Server and ESXi host clusters.
When I/O lters are deployed on the ESXi cluster, vCenter Server automatically congures and registers an
I/O lter storage provider, also called a VASA provider, for each host in the cluster. The storage providers
communicate with vCenter Server and make data services oered by the I/O lter visible in the VM Storage
Policies interface. You can reference these data services when dening common rules for a VM policy. After
you associate virtual disks with this policy, the I/O lters are enabled on the virtual disks.
See vSphere Storage for more information.
Storage I/O Control Requirements
Storage I/O Control has several requirements and limitations.
n
Datastores that are Storage I/O Control-enabled must be managed by a single vCenter Server system.
n
Storage I/O Control is supported on Fibre Channel-connected, iSCSI-connected, and NFS-connected
storage. Raw Device Mapping (RDM) is not supported.
n
Storage I/O Control does not support datastores with multiple extents.
n
Before using Storage I/O Control on datastores that are backed by arrays with automated storage tiering
capabilities, check the VMware Storage/SAN Compatibility Guide to verify whether your automated tiered
storage array has been certied to be compatible with Storage I/O Control.
Automated storage tiering is the ability of an array (or group of arrays) to migrate LUNs/volumes or
parts of LUNs/volumes to dierent types of storage media (SSD, FC, SAS, SATA) based on user-set
policies and current I/O paerns. No special certication is required for arrays that do not have these
automatic migration/tiering features, including those that provide the ability to manually migrate data
between dierent types of storage media.
vSphere Resource Management
50 VMware, Inc.