Without vSphere Distributed Resource Scheduler, your virtual machines would pile up on a few physical servers while others sit nearly empty, causing slowdowns, crashes, and wasted hardware. This technology is the automatic load balancer that keeps every virtual machine running smoothly, and for the VCP-DCV exam you must understand exactly how it works and how to configure it. It is the difference between a well-managed data centre and a chaotic one that constantly falls over.
Jump to a section
A simple way to picture vSphere Distributed Resource Scheduler
Seven food trucks are parked at a busy weekend festival. Each truck has its own speciality: tacos, burgers, dumplings, and so on. Trucks 1, 4, and 6 are slammed with long queues; customers are waiting 15 minutes for a burger. Meanwhile, trucks 2, 3, 5, and 7 are idle, with cooks leaning against their counters. The festival organiser, Maria, watches this from her central screen. Maria has a rule: no customer should wait more than 10 minutes, and every truck must stay within 20% of the festival's average sales-per-hour. Maria sees the imbalance and signals Truck 1 to send two cooks to Truck 5, and sends a portable grill to Truck 6. She also tells Truck 3 to move to a busier corner of the field. Throughout the day, Maria automatically reassigns cooks, ingredients, and even moves trucks, always following her pre-set rules so that every customer gets served quickly and no truck is overworked or underused. She never gives a truck more orders than it can handle, and never lets a truck sit idle while others struggle. This is exactly what vSphere Distributed Resource Scheduler does for a cluster of virtual machines. Just as Maria balances the workload across her trucks, DRS continuously monitors the computing resources available to every virtual machine and moves them — or the resources they need — so that the whole system runs smoothly, efficiently, and within the rules you set.
Let us start with the basics. In a data centre, you have physical servers: these are actual computers with CPUs (the brains), memory (the short-term workspace), and storage (the filing cabinet). On top of these physical servers, you run virtual machines (VMs). Each VM is a software-based computer that behaves like a real one, running its own operating system and applications. A group of physical servers that work together is called a cluster.
Before vSphere DRS existed, if a VM needed more CPU power than its host physical server could provide, the VM would simply slow down or crash. If a physical server failed, all the VMs on it stopped working. An administrator had to manually move VMs from an overloaded host to an underloaded one, a tedious and error-prone process. Even worse, you might have 10 physical servers, but one might be at 90% CPU usage while four others sit at 10%. This is inefficient and expensive.
vSphere Distributed Resource Scheduler (DRS) is a feature built into VMware vSphere that fixes this problem automatically. Think of DRS as an intelligent traffic controller inside your cluster of physical servers. Its job is to constantly watch the resource usage — specifically CPU and memory — of every VM and every host in the cluster. When it detects an imbalance — for example, one host is overwhelmed while another has spare capacity — DRS moves VMs from the busy host to the idle one, without stopping them. This movement is called vMotion. vMotion is a technology that migrates a running VM from one physical server to another with zero downtime; the user never notices a thing.
DRS works by using a system of thresholds. You, the administrator, set a level of aggressiveness for DRS, from conservative to aggressive. A conservative setting means DRS only moves VMs when there is a severe imbalance. An aggressive setting means DRS moves VMs often to maintain near-perfect balance. There are five levels, from 1 (most conservative) to 5 (most aggressive), plus a fully automated mode where DRS makes all decisions and a manual mode where it only suggests moves you must approve.
Here is what DRS considers when making decisions:
Current CPU usage of every host and VM.
Current memory usage of every host and VM.
The number of VMs on each host.
Any rules you have set, such as affinity or anti-affinity rules.
The migration cost: moving a VM uses resources, so DRS weighs the benefit against the cost.
DRS runs an evaluation every 5 minutes by default, and also when a VM is first powered on. At that moment, DRS decides the best host to place the VM on, which is called initial placement. This prevents the VM from ever starting on an overloaded host.
But DRS is not a magic wand. It works within a resource pool. A resource pool is a container where you group VMs and give them minimum and maximum shares of CPU and memory. DRS respects these limits. For example, if you have a resource pool for test servers that only gets 20% of total CPU, DRS will not give that pool more resources even if hosts are idle elsewhere.
DRS also works hand-in-hand with other features. When combined with VMware High Availability (HA), which restarts VMs after a host failure, DRS rebalances the cluster after the failed host is returned to service. When combined with VMware Distributed Power Management (DPM), DRS can even consolidate VMs onto fewer hosts during low-usage periods and power down idle hosts to save electricity.
Why does this matter for the VCP-DCV exam? Because you will be asked to configure DRS, understand its automation levels, troubleshoot when it does not work as expected, and create rules that override its default behaviour. You must know the difference between manual, partially automated, and fully automated modes. You must know when to use affinity rules versus anti-affinity rules. And you must understand what happens if you put a host in maintenance mode — DRS automatically evacuates all VMs from that host before it shuts down.
In essence, DRS transforms a static collection of physical servers into a dynamic, self-managing pool of resources. It saves administrators from repetitive manual work, prevents performance problems before they happen, and makes the entire data centre more efficient. For the exam, you do not need to memorise every algorithm inside DRS, but you must be confident in its purpose, its configuration options, and how it interacts with other vSphere features.
Enable DRS on a Cluster
In the vSphere Web Client, you select the cluster, go to the 'Configure' tab, then 'Services' and click 'Edit' next to DRS. Here you check the box 'Turn ON vSphere DRS'. This activates DRS for the entire cluster. Without this step, DRS does nothing and you must manually migrate VMs.
Set the Automation Level
You choose Manual, Partially Automated, or Fully Automated. For most production environments, Fully Automated is used with a moderate threshold. This choice determines whether DRS will move VMs without asking you. The exam will test your ability to identify which level fits a given scenario.
Configure the Migration Threshold
You adjust the slider from 1 (Conservative) to 5 (Aggressive). The default is 3. This tells DRS how big an imbalance must be before it acts. A lower number means fewer but more impactful migrations; a higher number means DRS will make many small adjustments. You should understand the trade-off between perfect balance and migration overhead.
Create Affinity or Anti-Affinity Rules
In the 'Configure' tab under 'VM/Host Rules', you click 'Add' to create a rule. You choose whether it is an affinity rule (VMs should run together) or anti-affinity rule (VMs must run apart). You then select the VMs the rule applies to. For example, two domain controllers should be on separate hosts for redundancy, so you create an anti-affinity rule for them.
Override DRS for an Individual VM (Optional)
Sometimes a specific VM should not be moved by DRS, perhaps because it uses a hardware device that vMotion does not support. In the VM's settings, you can set a DRS override to disable DRS for that VM or set a different automation level. This is done under 'VM Overrides' in the cluster settings.
Monitor DRS Recommendations
Even in fully automated mode, you can view the 'Monitor' tab in the cluster to see what DRS recommended and what actions it took. This helps you understand if DRS is behaving as expected. If you see unwanted migrations, you can adjust the threshold or create rules to prevent them.
Place a Host into Maintenance Mode
When you right-click a host and select 'Enter Maintenance Mode', DRS will begin migrating all VMs off that host to other hosts in the cluster. If DRS is disabled or set to manual, you must manually migrate or shut down VMs before the host can enter maintenance mode. This step is critical for hardware upgrades or repairs.
Imagine you are the IT administrator for a medium-sized e-commerce company that runs all its business applications on vSphere. You have a cluster of four physical servers, each with 256 GB of memory and 16 CPU cores. On this cluster, you run 30 VMs: web servers, database servers, application servers, and a few development test machines. Without DRS, you would manually track usage and move VMs when a host gets too hot. This is not only tedious but also risky — if you misjudge, you could cause a VM to become unresponsive.
Here is what a real workday looks like with DRS:
You configure the cluster with DRS set to fully automated at level 3 (moderate aggressiveness). This means DRS will automatically migrate VMs to maintain balance, and you trust it to do so.
A big sales promotion starts at 10:00 AM. At 9:45 AM, you power on three new web server VMs to handle the expected traffic. DRS automatically places each new VM on the host with the most available resources at that moment. One VM goes to Host 1, one to Host 3, and one to Host 4. This is initial placement.
By 10:30 AM, Host 2 is running at 90% CPU usage because it is hosting the database VMs that are working hard during the sale. Meanwhile, Host 1 is at 40%. DRS notices this imbalance and checks the situation. It sees that moving one of the busier VMs from Host 2 to Host 1 would reduce overall imbalance. DRS initiates a vMotion, transferring the VM while it is still running. The database never goes offline.
At 2:00 PM, the sales spike is over, and you want to perform maintenance on Host 3, which needs a firmware update. You place Host 3 into maintenance mode. DRS immediately begins evacuating all VMs from Host 3 to the other three hosts. It considers affinity rules — you have an anti-affinity rule that says two particular VMs must never run on the same host. DRS respects this and places them on separate hosts. Within minutes, Host 3 is empty and ready for maintenance.
After maintenance, you bring Host 3 back online. DRS automatically rebalances the cluster by moving some VMs back to Host 3 to even out the workload again.
At 5:00 PM, you check the DRS history logs. You see that yesterday DRS performed 12 migrations. Without DRS, you would have had to do all those moves manually, or your VMs would have suffered performance issues. You also notice that DRS rejected a migration because the migration cost (the resource overhead of moving the VM) was higher than the benefit. This is normal, and you can adjust the threshold if needed.
This scenario shows that DRS is not just a nice-to-have; it is essential in any production environment where uptime and performance matter. An IT professional does not sit around watching dashboards all day. They set rules, configure thresholds, and then DRS does the heavy lifting. When it does not behave as expected, they check the DRS recommendations, look at historical data, and adjust settings. They also use DRS in combination with resource pools to guarantee minimum performance for critical VMs while allowing others to fight for spare capacity.
The exam will test you on scenarios like this, asking what DRS will do when a host enters maintenance mode, or how to configure a rule to keep two VMs apart. So practise by setting up a small cluster in a lab environment and watching DRS work.
The VCP-DCV exam tests vSphere Distributed Resource Scheduler in several specific ways. You will not be asked to explain the entire history of DRS, but you will be asked to make decisions about configuration, trouble-shooting, and rule creation. Here is exactly what you need to focus on:
Automation levels: The exam will ask you to identify the three automation levels: Manual, Partially Automated, and Fully Automated. You must know that in Manual mode, DRS only generates migration recommendations that you must approve. In Partially Automated mode, DRS automatically applies initial placement but requires approval for migrations. In Fully Automated mode, DRS does everything automatically based on the migration threshold you set. The exam loves to present a scenario and ask which mode is in use.
Migration threshold: There are five settings (1 to 5), ranging from Conservative to Aggressive. The default is level 3. The exam may ask what happens if you set it to level 5 (aggressive) — expect more frequent migrations, which can cause overhead. They may also ask which setting would lead to fewer migrations — that is level 1.
DRS host monitoring: The exam tests that DRS monitors both CPU and memory usage. It does not monitor storage or network I/O for DRS decisions (that is a separate feature called Storage DRS). Do not confuse the two.
Affinity and anti-affinity rules: These are heavily tested. An affinity rule says two VMs should run on the same host. An anti-affinity rule says they must never run on the same host. The exam will give you a scenario — for example, two VMs that must never be on the same host because of licensing — and ask you to choose the correct rule type. There is also a VM-Host affinity rule that says a VM must run on a specific host or group of hosts. Know the difference between these rule types.
Common trap: The exam might try to trick you into thinking DRS works across clusters. It does not. DRS works within a single cluster. It also does not work across data centres. The scope is the cluster.
Another trap: DRS does not migrate VMs that are using a vGPU (virtual GPU) unless certain conditions are met. This is a niche area but appears in some questions.
Troubleshooting: The exam will ask what to do if DRS is not making recommendations. Possible answers: check if DRS is enabled, check the automation level, verify that hosts are in the cluster and not disconnected, and ensure there are no resource pools with strict limits.
Maintenance mode: You must know that when a host enters maintenance mode, DRS evacuates all VMs from that host. If DRS is disabled or set to manual, you must manually migrate or shut down VMs before the host can enter maintenance mode. The exam loves this sequence.
Initial placement: DRS places new VMs on the host with the best resource availability. This happens even in Manual mode if you have it set to partially automated or fully automated for initial placement. The exam will ask what happens when you power on a new VM.
DRS and EVC (Enhanced vMotion Compatibility): EVC ensures that all hosts in the cluster present the same CPU features to VMs, making vMotion possible. The exam may tie these together, asking why a VM cannot be migrated despite DRS being enabled — the answer could be incompatible CPU features, which EVC would solve.
Memory overcommitment: The exam expects you to know that DRS considers memory usage, not just allocation. High memory usage on a host will trigger DRS to move VMs, even if the CPU is fine.
Recommend your own lab: The best way to prepare is to build a two-host cluster in VMware Workstation or a home lab, enable DRS, and create VMs. Watch the recommendations. Try setting different automation levels. Create an anti-affinity rule and see how DRS respects it. This hands-on time is invaluable for the exam.
DRS constantly monitors CPU and memory usage across all hosts in a cluster and automatically moves VMs to balance the load using vMotion.
DRS operates at three automation levels: Manual (only recommendations), Partially Automated (automatic initial placement, manual migrations), and Fully Automated (everything automatic).
Affinity rules make VMs run together on the same host; anti-affinity rules force them to run on separate hosts for high availability or licensing reasons.
DRS only works within a single cluster and requires shared storage for vMotion to function correctly.
When a host is put into maintenance mode, DRS automatically evacuates all VMs from that host to other hosts in the cluster.
The migration threshold slider from 1 (conservative) to 5 (aggressive) controls how aggressively DRS moves VMs to achieve balance, with level 1 reducing migrations and level 5 increasing them.
DRS performs initial placement of new VMs onto the most suitable host, which even happens in partially automated mode.
These come up on the exam all the time. Here's how to tell them apart.
DRS (Distributed Resource Scheduler)
Balances CPU and memory load across hosts in a cluster.
Uses vMotion to migrate running VMs without downtime.
Prevents performance problems by proactive load balancing.
HA (High Availability)
Restarts VMs on other hosts after a host failure.
Does not move running VMs; it powers them back on.
Reacts to crashes and failures, not performance issues.
Affinity Rule
Specifies that VMs should run on the same host.
Used to keep VMs together for performance or licensing.
DRS will try to place and keep those VMs on one host.
Anti-Affinity Rule
Specifies that VMs must run on different hosts.
Used for redundancy: VMs that provide the same service should not be on the same host.
DRS will keep those VMs separate even if it causes imbalance.
Manual Automation Level
DRS only provides migration recommendations; you must approve each one.
Initial placement of new VMs is not automatic.
Gives you full control but requires constant monitoring.
Fully Automated Automation Level
DRS automatically applies both initial placement and migrations.
You can set a migration threshold to control aggressiveness.
Hands-off operation, suitable for most production environments.
DRS
Balances VM placement based on CPU and memory usage.
Operates at the cluster level of hosts.
Uses vMotion to migrate VMs between hosts.
Storage DRS
Balances VM storage placement based on storage capacity and I/O latency.
Operates within a datastore cluster (a group of storage volumes).
Uses Storage vMotion to migrate VM files between datastores.
Initial Placement
Occurs when a VM is powered on for the first time.
DRS selects the best host based on current resource availability.
Happens even in Partially Automated mode.
Migrated Placement (rebalancing)
Occurs later when DRS detects an imbalance.
Involves moving a VM that is already running.
Only happens in Fully Automated mode or if you approve recommendations.
Mistake
DRS balances virtual machines evenly across all hosts, meaning each host ends up with the same number of VMs.
Correct
DRS balances based on resource usage (CPU and memory), not the count of virtual machines. One host might have five small VMs while another has one big VM, and DRS will adjust based on actual load.
People confuse 'balance' with 'equal distribution of VMs'. This mistake is common because the word 'balance' usually means equal distribution in everyday life, like balancing a scale.
Mistake
DRS works with any type of storage, including local storage that is not shared between hosts.
Correct
DRS requires shared storage, such as a SAN or NAS, because vMotion needs the VM's files to be accessible from any host in the cluster. Without shared storage, DRS cannot migrate running VMs.
Beginners do not realise that vMotion, which DRS depends on, requires the VM's storage to be available to both the source and destination hosts. They assume DRS can move VMs even if the hosts do not share storage.
Mistake
DRS automatically fixes any performance problem by moving VMs away from any slow host immediately.
Correct
DRS will only move a VM if the benefit outweighs the cost of migration. If the host is barely overloaded, DRS may wait. Also, DRS only addresses CPU and memory imbalance, not storage latency, network congestion, or application-level performance issues.
People assume DRS is a universal performance cure. They do not understand that DRS has thresholds and a cost/benefit analysis, and that it does not monitor everything.
Mistake
If DRS is set to fully automated, it will move any VM any time, even if that VM is critical and moving it would cause a brief interruption in network connectivity.
Correct
DRS vMotion moves a running VM with zero downtime and no interruption to the operating system or applications. However, vMotion does have some constraints: it cannot move VMs with some hardware devices attached (like PCIe passthrough) without special configuration. The exam tests these constraints.
People familiar with older or non-VMware hypervisors may think migration always causes downtime. They also may not know that vMotion is seamless, which is a key feature of VMware.
Mistake
You must manually turn on DRS for every new cluster you create.
Correct
In the vSphere Web Client, DRS is enabled per cluster and can be turned on during cluster creation or later. Once enabled, it applies to all VMs on that cluster unless overridden by individual VM settings (VM override). The exam tests that you know where to enable it and that you can override it per VM.
Many students think DRS is a per-VM or per-host feature. The cluster scope is often misunderstood, leading to exam errors.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No, DRS operates only within a single cluster. It cannot migrate VMs between clusters. To move VMs between clusters, you would need to use vMotion manually or a feature like Cross-Cluster vMotion.
If you disable DRS, the cluster stops automatically balancing VMs. Any VMs currently running will stay where they are, and new VMs will be placed on the host you manually choose or the host with the least load at that moment, but no automatic rebalancing occurs.
Yes, DRS uses vMotion to migrate running VMs, and vMotion operates with zero downtime. The VM stays powered on throughout the move, and users do not experience any interruption.
DRS is for load balancing and initial placement of VMs. VMware High Availability (HA) is for restarting VMs after a host failure. They work together but solve different problems: one prevents performance issues, the other handles crashes.
Yes, DRS can move such VMs as long as the ISO is stored on shared, accessible storage. If the ISO is on a local drive of the source host, vMotion will fail. The exam may test this as a potential reason why a VM cannot be migrated.
A VM override allows you to change the DRS behaviour for a specific VM. For example, you can set a critical database VM to 'Manual' mode so DRS only recommends moves but does not automatically migrate it, while the rest of the cluster remains fully automated.
You've finished vSphere Distributed Resource Scheduler. Continue through the VCP-DCV study guide to build a complete picture of the exam.
Done with this chapter?