What is DRS in VMware vSphere?

Distributed Resource Scheduler (DRS) is a VMware vSphere clustering

feature that allows you to load balance VMs running in the cluster. DRS
checks the VM load and a load of ESXi servers within a vSphere cluster.
If DRS detects that there is an overloaded host or VM, DRS migrates the
VM to an ESXi host with enough free hardware resources to ensure the
quality of service (QoS). DRS can select the optimum ESXi host for a VM
when you create a new VM in the cluster.
VMware DRS allows you to run VMs in a balanced cluster and avoid
overloading and situations when there are not enough hardware
resources for virtual machines and applications running on VMs for
normal operation (there must be enough resources in the whole cluster
in this case).

DRS Requirements
The requirements for DRS, along with the general requirements for a
vSphere cluster, include:
 vSphere Enterprise or vSphere Enterprise Plus license
 A CPU with Enhanced vMotion Compatibility for VM live migration with
vMotion
 A dedicated vMotion network
A configured VMware vMotion is required to operate a DRS cluster,
unlike an HA cluster, where vMotion is required only if using Fault
Tolerance. Also, the vSphere license required for VMware DRS is higher
than the license for using vSphere High Availability.

The role of vMotion

Migrate VMs from one ESXi host to another with vMotion, which we
mentioned when explaining how Fault Tolerance works. With VMware
vMotion, VM migration (CPU, memory, network state) occurs without
interrupting running VMs (there is no downtime). VMware vMotion is
the key feature for the proper work of DRS.
Let’s look at the main steps of vMotion operation:
1. vMotion creates a shadow VM on the destination ESXi host. The
destination ESXi host pre-allocates enough resources for the VM to be
migrated. The VM is put in the intermediate state and the VM
configuration cannot be changed during migration.

2. The precopy process. Each VM memory page is copied from the

source to the destination by using a vMotion network.
3. The next pass of copying memory pages from the source to the
destination is performed, because memory pages are being changed
during the VM operation. This is an iterative process that is performed
until no changed memory pages remain. The changed memory pages
are called dirty pages. It takes more time for VM migration with vMotion
if memory-intensive operations are performed on a VM because more
memory pages are changed.
4. The VM is stopped on the source ESXi host and resumed on the
destination host. Insignificant network latency can be noticed inside the
migrated VM for about a second at this moment.
The Working Principle of DRS in VMware
VMware DRS checks the workloads from the CPU and RAM perspectives
to determine the vSphere cluster balance every 5 minutes, which is the
default interval. VMware DRS checks all of the resources in the resource
pool of the cluster, including the resources consumed by VMs and the
resources of each ESXi host within the cluster that can be provided to
run VMs. Resource checks are performed according to the configured
policies.
The demands of VMs are also taken into account (the hardware
resources that the VM needs to run at the moment of checking). The
formula is used for VM demand calculation for memory:
VM memory demand = Function(Active memory used, Swapped,
Shared) + 25% (idle consumed memory)
CPU demand is calculated based on the number of processor resources
that are currently consumed by a VM. VM CPU maximum values and
VM CPU average values collected during the last check help the DRS to
determine the trend of resource usage for a particular VM. If vSphere
DRS detects an imbalance in the cluster and that some ESXi hosts are
overloaded, then the DRS initiates live migration of VMs running on the
overloaded host to a host with free resources.
Let’s look at how vSphere DRS works in VMware using an example with
diagrams. In the diagram below, you can see a DRS cluster with 3 ESXi
hosts. All the hosts are connected to shared storage, where VM files are
located. The first host is very loaded, the second host has free CPU and
memory resources, and the third host is heavily loaded. Some VMs on
the first (VM1) and third (VM4, VM5) ESXi hosts are consuming almost
all the provisioned CPU and memory resources. In this case, the
performance of these VMs can degrade.
VMware DRS determines that the rational action is to migrate the
heavily loaded VM2 from the overloaded ESXi host 1 to ESXi host 2,
which has enough free resources and migrate VM4 from ESXi host 3 to
ESXi host 2. If the DRS is configured to work in the automatic mode,
then running VMs are migrated with vMotion (this action is illustrated
with green arrows in the image below). VM files including virtual disks
(VMDK), configuration files (VMX), and other files are located in the
same place on the shared storage during VM migration and after VM
migration (connections of VMs and their files are illustrated with dotted
lines on the image).
Once the selected VMs have been migrated, the DRS cluster becomes
balanced. There are free resources on each ESXi host within the cluster
to run VMs effectively and ensure high performance.
The situation can change due to uneven VM workloads, and the cluster
can become imbalanced again. In this case, DRS will check the
resources consumed and free resources in the cluster to initiate VM
migration again.

Key Parameters for vSphere DRS

Configuration
VMware vSphere DRS is a highly customizable clustering feature that
allows you to use DRS with higher efficiency in different situations. Let’s
look at the main parameters that affect the behavior of DRS in a
vSphere cluster.

VMware DRS automation levels

When DRS detects that a vSphere cluster is imbalanced, DRS provides
recommendations for VM placement and migration with vMotion. The
recommendation can be implemented by using one of three
automation levels:
Fully automated. Initial VM placement and vMotion recommendations
are applied automatically by DRS (user intervention is not required).
Partially automated. Recommendations for the initial placement of
new VMs are the only ones applied automatically. Other
recommendations can be initiated and applied manually or ignored.
Manual. DRS provides recommendations for initial VM placement and
VM migration but user interaction is required to apply these
recommendations. You can also ignore the recommendations provided
by DRS.

DRS aggression levels (migration thresholds)

 DRS aggression levels or migration thresholds is the option to control
the maximum imbalance level that is acceptable for a DRS cluster.
There are five threshold values from 1, the most conservative, to 5, the
most aggressive.
The aggressive setting initiates VM migration even if the benefit of VM
placement is slight. The conservative setting doesn’t initiate VM
migration even if significant benefits can be achieved after VM
migration. Level 3, the middle aggression level, is selected by default
and this is the recommended setting.

Affinity Rules in VMware DRS

Affinity and anti-affinity rules are useful when you need to place
specific VMs on specific ESXi hosts. For example, you may need to run
some VMs together on one ESXi host within a cluster, or vice versa (you
need two or more VMs to be placed only on different ESXi hosts, and
VMs must not be placed on one host). Use cases can include:
 Virtual domain controller VMs (a primary domain controller and
additional domain controller) on different hosts to avoid the failure of
both VMs if one host fails. These VMs must not run together on a single
ESXi host in this case.
 VMs running software that is licensed to run on the appropriate
hardware and cannot run on other physical computers due to licensing
limitations (for example, Oracle Database).
Affinity rules are divided into:
 VM-VM affinity rules (for individual VMs)
 VM-host affinity rules (relationship between groups of hosts and groups
of VMs)
VM host rules can be preferential (VMs should…) and mandatory (VM
must…). Mandatory rules continue to work even if DRS is disabled,
which doesn’t allow you to migrate the appropriate VMs with vMotion
manually. This principle is used to avoid violation of the rule applied to
VMs running on ESXi hosts if vCenter is temporarily unavailable or
failed.
There are four options for DRS affinity rules:
Keep virtual machines together. The selected VMs must run together
on a single ESXi host (if VM migration is needed, all these VMs must be
migrated together). This rule can be used when you want to localize
network traffic between the selected VMs (to avoid network
overloading between ESXi hosts if VMs generate significant network
traffic). Another use case is running a complex application that uses
components (that depend on each other) installed on multiple VMs or
running a vApp. This could include, for example, a database server and
an application server.
Separate virtual machines. The selected VMs must not run on a single
ESXi host. This option is used for high availability purposes.
Virtual machines to hosts. VMs added to a VM group must run on the
specified ESXi host or host group. You need to configure DRS groups
(VM/Host groups). A DRS group contains multiple VMs or ESXi hosts.
Virtual machines to virtual machines. This rule can be selected to tie
VMs to VMs when you want to power on one VM group and then power
another (dependent) VM group. This option is used when VMware HA
and DRS are configured together in the cluster.
If there is a rule conflict, then the older rule takes precedence.

VM Override for VMware DRS

Similar to the use of VM override in a vSphere HA cluster, VM overrides
are used for more granular configurations of DRS in VMware vSphere
and allow you to override global settings set at the DRS cluster level
and define specific settings for an individual VM. Other VMs of the
cluster are not affected when VM override is applied for a specific VM.

Predictive DRS
The main concept of Predictive DRS is to collect information about VM
placement and then, based on the previously collected information,
predict when and where high resource usage will occur. Using this
information, Predictive DRS can move VMs between hosts for better
load balancing before an ESXi server is overloaded and VMs lack
resources. This feature can be useful when there are time-based
demand changes for VMs in a cluster. Predictive DRS is disabled by
default. VMware vRealize Operations Manager is required to use Power
DRS.
Distributed Power Manager
Distributed Power Manager (DPM) is a feature used to migrate VMs if
there are enough free resources in a cluster to shut down an ESXi host
(put a host into the standby mode) and run VMs on the remaining ESXi
hosts within the cluster (remaining hosts must provide enough
resources to run the needed VMs).
When more resources are needed in a cluster to run VMs, DPM initiates
a server that was shut down to wake up and operate in normal mode.
One of the supported power management protocols is used to power
on a host via the network. These protocols are Intelligent Platform
Management Interface (IPMI), Hewlett-Packard Integrated Lights-Out
(iLO), or Wake-On-LAN (WOL). Then DRS migrates some VMs to this
server to distribute workloads and balance a cluster. By default,
Distributed Power Management is disabled. DPM recommendations
can be applied automatically or manually.
Storage DRS
While DRS migrates VMs based on CPU and RAM computing resources,
Storage DRS migrates virtual machine files from one datastore to
another based on datastore usage, for example, free disk space. Affinity
and anti-affinity rules allow you to configure whether Storage DRS must
store a VM’s virtual disk files together on the same datastore. For
example, you can configure the anti-affinity rule to store the VMDK files
of a VM that performs I/O intensive operations on different datastores.
You do this to avoid performance degrading of the VM and initial VM
datastore (I/O disk workloads will be distributed across multiple
datastores when using the anti-affinity rule).
Storage DRS is useful when using VMs with thin provisioned disks in
case of overprovisioning. Storage DRS helps avoid situations when the
size of thin disks grows, and as a result, there is no free space on a
datastore. Lack of free space causes the VMs storing virtual disks on
that datastore to fail. Virtual machine disk files can be migrated from
one datastore to another with Storage vMotion while the VM is running.

Monitoring CPU and memory consumption

VMware provides the ability to monitor resource usage in the web
interface of VMware vSphere Client. You can monitor CPU usage in the
cluster by going to Settings > Monitor > vSphere DRS > CPU Utilization.
There are also other options for monitoring the memory and storage
space for separate ESXi hosts. VMware monitoring is supported in
NAKIVO Backup & Replication 10.5. Read more about infrastructure
monitoring in the blog post.

Using VMware HA and DRS Together

VMware HA and DRS are not competing technologies. They
complement each other, and you can use both VMware DRS and HA in
a vSphere cluster to provide high availability for VMs and balance
workloads if VMs are restarted by HA on other ESXi hosts. It is
recommended that you use both technologies in vSphere clusters
running in production environments for automatic failover and load
balancing.
When an ESXi host fails, VM failover is initiated by HA, and VMs are
restarted on other hosts. The first priority in this situation is to make
VMs available. But after VM migration, some ESXi hosts can be
overloaded, which would have a negative impact on VMs running on
those hosts. VMware DRS checks the resource usage on each host
within a cluster and provides recommendations for the most rational
placement of VMs after a failover. As a result, you can always be sure
that there are enough resources for VMs after failover to run workloads
with proper performance. With both VMware DRS and HA enabled you
can have a more effective cluster.

You can find VM Overrides at the Cluster level under

the Configure menu. In the image below, you can see that you
select vCluster. Go to Configure, and under Configuration click on VM
Overrides.
 VM Overrides Option at the cluster level

The DRS cluster can have the automation level configured as Fully
Automated. In this case, all VMs are moved around to accommodate the
host's load, and no single host is overloaded.
You can configure the VM Override to Manual; in which case, the VM is
excluded from the cluster-wide configuration.
This is pretty handy in many scenarios where you do not want a particular
VM to be moved around by DRS; for example, a vCenter Server VM (or
VCSA).
There are four options in all:

 Disabled – You will disable DRS automation completely for this VM.
 Manual – You will receive notifications from your DRS for manual
vMotion tasks.
 Partially Automated – This option provides an initial placement
automatically. However, migration recommendations are only
displayed; they do not run.
 Fully Automated – This option provides default settings on a per-
cluster basis.
 VM Overrides for vSphere DRS

On the same screen, you can set options for what happens with this VM
when there is an HA failover. A VM can have various restart priorities. You
can choose from the following options: Lowest, Low,
Medium, High, Highest, and Disabled.
In our case of a VMware vCenter server VM, you would want to use
the Highest option, since this VM must be restarted before anything else--
perhaps even before a domain controller VM, since the initialization of the
internal DB takes at least five minutes.
 VM Overrides for vSphere HA

Each virtual machine in a vSphere HA cluster is assigned the cluster

default settings for VM Restart Priority.
You can change the default behavior for each virtual machine by changing
these defaults. However, If the virtual machine leaves the cluster, these
settings are lost, because they are settings at the cluster-level.
During migration of VMs from one datacenter to another, you should
always check these rules and exceptions. Otherwise, they're simply lost.
They do not migrate along with a particular VM(s).
Note: If you plan to use vSphere fault tolerance, you should keep in mind
that DRS will not move fault tolerance–enabled virtual machines.

Microsoft Cluster Service (MSCS) virtual machines ^

If you have any Microsoft Clustered VMs, the automation level of all virtual
machines in an MSCS cluster should be set to Partially Automated. This
is VMware's recommendation.
When you set the vSphere DRS automation level for the virtual machine
to Partially Automated, vCenter Server will perform an initial placement of
VMs when they are powered on and will provide migration
recommendations for them. (Not actual vMotion.)
So let's say you have three VMs with a Microsoft MSCS configuration. In
this case, you should select all three VMs and apply this configuration so
that they will not be affected by DRS and vMotion but will still be protected
by VMware High Availability (HA) and will be restarted if the underlying
hardware has any problems.