Picture a kitchen with four chefs on the line. One of them is buried under twelve orders while another is standing around wiping a clean counter. A good head waiter notices, walks an order or two over to the idle chef, and the whole kitchen speeds up. Nobody at the tables sees any of this. That head waiter is DRS, the chefs are your ESXi hosts, and the orders are virtual machines.
Without something like DRS, somebody has to be that head waiter by hand. You log in, notice one host is at ninety percent memory while its neighbour is half empty, and you manually vMotion a few VMs across. That works until you have fifty hosts and it is two in the morning. DRS does the watching and the moving for you, every single minute.
What DRS actually is
First, one word you need: a cluster. A cluster is a group of ESXi hosts that vCenter manages as a single pool of CPU and memory. You stop thinking about ten separate servers and start thinking about one big bucket of resources. DRS is the feature that makes that bucket behave like a bucket instead of ten stubborn boxes.
DRS stands for Distributed Resource Scheduler. It lives in vCenter, not on the hosts, so no vCenter means no DRS. It has one goal: make sure every VM gets the CPU and memory it is asking for, by spreading VMs across the hosts so none of them is gasping while another sits idle. When it needs to rebalance, it does not shut anything down. It calls vMotion (Part 9) to move a running VM with no downtime.
The two jobs of DRS
1. Initial placement
When you power on a VM, DRS picks the best host for it right then. It looks at how much CPU and memory each host has free and drops the VM onto the host that gives it the most room. This is the part of DRS that runs even in the lightest setting, and it is the part freshers underrate. Good placement at power-on means DRS rarely has to move anything later.
2. Ongoing load balancing
Workloads change through the day. A VM that was quiet at lunchtime might be hammering its CPU by evening. DRS keeps watching, and when one host becomes a hotspot it vMotions one or more VMs off it onto a quieter host. The diner never notices the order moved to another chef.
How DRS decides what to move
This is where the modern version is genuinely different from what older blog posts describe, so it is worth getting right. In vSphere 6 and earlier, DRS was cluster-centric: every five minutes it calculated one cluster imbalance number and shuffled VMs to flatten it. From vSphere 7 onward, DRS became VM-centric. It now calculates a VM DRS score for every VM on every host in the cluster, and it does this every 60 seconds, not every five minutes.
The DRS score is a measure of how happy a VM is on its current host: how much of the CPU and memory it wants is it actually getting, and how much would it cost to move it. A high score means the VM is well fed where it sits. DRS uses these scores to decide whether moving a VM would meaningfully improve things. A nice side effect of the newer design: it prefers to move VMs with smaller memory, because a lighter VM is faster to vMotion and disturbs running applications less.
The migration threshold
The threshold is a slider from 1 to 5 that controls how eager DRS is to move VMs. The default is 3, sitting in the middle.
| Level | Name | What it means |
|---|---|---|
| 1 | Conservative | Only mandatory moves, such as putting a host in maintenance mode or enforcing a rule. |
| 2 | – | Moves that give a significant improvement. |
| 3 | Default | Moves that give at least a good improvement. The setting almost everyone runs. |
| 4 | – | Moves that give even a moderate improvement. |
| 5 | Aggressive | Any move that helps even slightly. Lots of vMotions. |
A real opinion
The official line is that level 3 suits most clusters, and I agree with the default. Where I part ways with a lot of online advice is the push toward aggressive settings. People crank the slider to 5 thinking tighter balance is always better. It is not. Every vMotion costs CPU, network, and a brief stun of the VM. Chasing a perfectly flat cluster at level 5 buys you a storm of migrations for a few percent of balance you will never feel. If your cluster looks lumpy, fix the real cause first: a wrong reservation, a noisy VM, or hosts that are simply too few. Reach for the slider last, not first.
Automation levels: who pulls the trigger
Separate from the threshold is the automation level, which decides whether DRS acts on its own or just suggests. There are three modes.
Here is the catch that bites freshers. Partially Automated sounds like it does half the work, and it does, but only the placement half. It will pick a host at power-on, then for ongoing balancing it just lists recommendations and waits for you to click apply. If nobody is watching the recommendations tab, those moves never happen and the cluster slowly goes lopsided while everyone assumes DRS is handling it. That is why production clusters almost always run Fully Automated.
In practice
When you are learning, switch your lab cluster to Partially Automated for a week. You will see the exact recommendations DRS wants to make and the reason for each one under Cluster, Monitor, vSphere DRS. It teaches you how DRS thinks. Then put production back to Fully Automated, because in real life nobody clicks the apply button at 2 am.
Affinity and anti-affinity rules
Sometimes you need to overrule DRS. Two kinds of rules let you do that. An affinity rule says keep these VMs on the same host, useful when two VMs chatter a lot and you want them close. An anti-affinity rule says keep these VMs apart, which is how you stop both nodes of a database cluster from landing on one host and dying together if that host fails. DRS respects these rules and works around them when it balances.
A worked example with real numbers
Worked example
Three ESXi hosts, each with 256 GB of RAM. The cluster total is 768 GB. Right now the VMs add up like this:
Host A: 220 GB used (86 percent). Host B: 80 GB used (31 percent). Host C: 110 GB used (43 percent).
Host A is the hotspot. If a VM on it asks for more memory, A has only 36 GB to give before it starts swapping and slowing down. DRS scores the VMs on A, picks two lighter ones (say 40 GB and 30 GB) and vMotions them to B. Now A sits at 150 GB, B at 150 GB, C at 110 GB. No host is above 60 percent, every VM has headroom, and not one of them was powered off to make it happen.
Notice DRS moved the small VMs, not the 100 GB monster on A. Moving the big one would have balanced the numbers too, but it would have taken far longer to migrate and stunned a bigger workload. Lighter is cheaper, so lighter wins.
Where DRS trips people up
The other quiet trap is forgetting that DRS and HA are different features doing different jobs. HA (Part 10) restarts VMs after a host dies. DRS keeps the survivors balanced. They run side by side in the same cluster and are configured separately. Mixing them up in your head leads to sentences like the cluster has DRS so it is highly available, which is wrong and which an interviewer will catch.
Real interview question
What is the difference between HA and DRS?
Answer it in one clean line and then show you know they cooperate. HA is about availability: when a host fails, HA restarts that host VMs on the surviving hosts. DRS is about performance and efficiency: it balances running VMs across healthy hosts using vMotion, and it picks the best host when a VM powers on. They are separate features in the same cluster. A strong follow-up answer: after HA restarts a pile of VMs onto whatever hosts had room, the cluster is now unbalanced, and DRS quietly tidies that up. That extra sentence is what makes an interviewer nod.
Try it yourself
In a free nested home lab (two nested ESXi hosts plus a vCenter, or VMware Workstation), do this:
1. Put both hosts in a cluster and turn on DRS in Partially Automated mode. 2. Power on three or four small test VMs and watch where DRS places them. 3. Open Cluster, Monitor, vSphere DRS and read the recommendations and the VM DRS scores. 4. Put one host into maintenance mode and watch DRS generate mandatory moves to evacuate it.
How to know it worked: when you enter maintenance mode, every VM should vMotion off that host on its own, because evacuating a host is a priority-1 mandatory move that even the most conservative threshold obeys. If they do not move, your vMotion network or shared storage is not set up right, and that is a useful thing to discover in a lab rather than in production.
FAQ
Is DRS the same as vMotion?
No. vMotion is the mechanism that moves a running VM between hosts. DRS is the decision-maker that decides when and which VM to move, and then calls vMotion to do it. vMotion can be used by hand without DRS, but DRS cannot rebalance without vMotion.
Does DRS work without shared storage?
For real load balancing, yes you need shared storage so any host can run any VM. DRS will still do initial placement at power-on, but it cannot freely vMotion VMs around to balance if their files live on local disk only.
Does DRS need vCenter?
Yes. DRS is a vCenter feature. The hosts themselves do not run DRS. If vCenter goes down, your VMs keep running but no new balancing happens until it is back.
How often does DRS check the cluster?
In vSphere 7 and later it calculates a DRS score for every VM every 60 seconds. Older versions ran every 5 minutes and were less granular.
Will DRS move my VMs constantly?
No, not at the default threshold. Most minutes it decides everything is fine and does nothing. It only moves VMs when the improvement clears the threshold, which is why level 3 stays calm while level 5 fidgets.
The takeaway
DRS is the feature that lets you stop babysitting individual hosts and start treating a cluster as one pool. Turn it on, leave it Fully Automated at threshold 3, set the odd affinity rule when an application demands it, and let it run. Understand the DRS score and the difference from HA, and you already know more about it than most people who have it switched on. Next we go a level deeper into how you tell DRS that some VMs matter more than others, with shares, limits, and reservations.
References
Broadcom TechDocs: DRS Migration Threshold
VMware: Load Balancing Performance of DRS in vSphere 7
VMware blog: A closer look at the VM DRS score
About The Author
DrJha