# Resource Management and Clusters

> Chapter 8 of the Courseiva VMWARE-VCP-DCV curriculum — https://courseiva.com/learn/vmware-vcp-dcv/resource-management-and-clusters

**Official objective:** 3.1 — Manage vSphere resources and configure clusters

## Introduction

The VCP-DCV exam objective 3.1 asks you to manage vSphere resources and configure clusters. This chapter solves a critical problem: how do you stop a single server failure from taking down your entire application? For someone studying VCP-DCV, understanding resource management and clusters is the difference between passing the exam and failing it, because this topic appears in at least 20% of questions.

## The Hotel Concierge Analogy

Have you ever been to a busy hotel where every guest wants something different at the same time? One guest needs ice, another wants a taxi, a third needs a new room key, and the front desk can only handle one request at a time. Without a good system, the lobby becomes a mess and guests get angry.

In a data center, the computer servers (called hosts) are like the hotel. The virtual machines — the guest operating systems that run your applications — are like the hotel guests. A vSphere cluster is the hotel management team. Instead of letting each host work alone, a cluster groups multiple hosts together so they behave like a single, smarter pool of resources. The cluster's brain, the vCenter Server, acts like a head concierge who knows every room's status. When a virtual machine needs more memory or CPU (like a guest requesting extra towels), the cluster automatically finds the best host to give it. If one host breaks down (like a lift going out of service), the cluster moves those virtual machines to healthy hosts without a shutdown — this is called vMotion. If many guests arrive at once (a spike in demand), the cluster can power up extra hosts automatically using a feature called Distributed Resource Scheduler (DRS).

This entire system replaces the old way where an administrator had to manually decide which server ran which virtual machine. It turns resource management from a chaotic mess into a smooth, automated operation that keeps everything running even when things go wrong.

## Core explanation

Resource management and clusters are the central nervous system of any vSphere environment. Let us break this down from the very beginning.

First, what is a resource in the context of vSphere? A resource is anything a virtual machine (a VM, which is a software-based computer that runs inside a physical computer) needs to operate. The four main resources are CPU (the processor that does calculations), memory (RAM, which holds active data), storage (hard drive space), and network bandwidth (the speed at which data moves). Every virtual machine claims a certain amount of these resources. If you run ten VMs on one physical host (a host is a physical server computer), they compete for the same pool of resources.

Now, what is a cluster? A cluster is a group of hosts (physical servers) that vCenter Server manages as a single object. Think of it as a team of servers that share their resources. When you create a cluster, you can enable powerful features that automate resource allocation and protect against failures.

The most important cluster feature is vSphere High Availability (HA). HA monitors every host in the cluster. If a host crashes (goes offline unexpectedly), HA automatically restarts all its virtual machines on other healthy hosts in the same cluster. This requires no manual intervention. The key here is that HA does not reboot the guest operating system inside the VM from a clean state — it restarts the VM itself, which is faster than booting from scratch, but the applications inside still need to boot up.

Next is vSphere Distributed Resource Scheduler (DRS). DRS continuously balances the workload across all hosts in a cluster. Imagine you have two hosts: Host A is running five busy VMs that max out its CPU, while Host B is idle. DRS sees this imbalance and automatically moves some VMs from Host A to Host B using a technology called vMotion. vMotion moves a running virtual machine from one host to another with zero downtime — the VM never shuts down. DRS operates on a scale from fully automated (it moves VMs without asking you) to manual (it only suggests moves that you approve).

Another critical feature is vSphere Distributed Power Management (DPM). DPM works with DRS. When the cluster has low overall demand, DPM powers down underused hosts to save electricity. When demand increases, it powers them back up. This is a huge cost saving in large data centers.

To make all this work, you must configure the cluster with the correct settings. You need to decide how many hosts to include (minimum is 1, but you need at least 2 for HA to work properly). You also need to set admission control for HA — this is a policy that reserves some capacity so that if a host fails, there is enough spare resources to restart its VMs. The three admission control policies are:

- Cluster resource percentage: Reserve a fixed percentage of total cluster resources for failover.
- Slot policy: Divide the cluster into equal-sized slots based on the largest VM, and reserve enough slots for a host failure.
- Dedicated failover host: Designate a specific host that stays empty and only takes over when another host fails.

DRS also has settings: how aggressively should it balance load? You can set it to conservative, moderate, or aggressive. There is also a per-VM automation level — you can mark a specific VM as 'manual' so DRS never moves it automatically.

Resource pools are another concept you need to know. A resource pool is a logical container that sets how resources are split among VMs. It is like dividing a pizza: you can give one department a bigger slice than another. Resource pools have shares (how much relative priority a VM gets when resources are contested), reservations (a guaranteed minimum), and limits (a maximum cap). For example, you could create a resource pool for the finance department with a reservation of 8 GB RAM and a limit of 16 GB, ensuring they always have at least 8 GB but never use more than 16 GB.

The old way of managing resources was to manually assign each VM to a specific host and hope that host had enough capacity. If it did not, you physically moved the VM to another host by shutting it down, moving the files, and booting it up — that process could take hours. Clusters eliminate that manual work. They also provide something called fault tolerance, where a second copy of the VM runs in lockstep on another host. If the primary host fails, the secondary copy takes over instantly — no interruption at all, though this uses double the resources.

Why do these features exist? Because modern businesses cannot tolerate downtime. A bank's payment system cannot go offline. An e-commerce website cannot be slow during Christmas sales. Clusters and resource management ensure that even if hardware breaks, the software keeps running.

For the VCP-DCV exam, you must memorise the exact differences between HA, DRS, and DPM. You also need to know the admission control policies and how resource pool shares work. The exam loves to ask: 'What feature should you use to automatically move VMs to balance load?' The answer is DRS. 'What feature restarts VMs after a host failure?' The answer is HA. 'What feature powers down unused hosts?' The answer is DPM.

## Real-world context

An IT professional does not just set up a cluster and forget it. Here is a concrete real-world scenario.

Imagine you work for a mid-sized retail company that has an online store. The company has 10 physical hosts in its data center. Before clusters, each host was dedicated to a specific application: one host for the web server, another for the database, another for email. If the web server host failed, the entire online store went down until you fixed the hardware and restored the VM from backup — a process that could take hours.

Now, with clusters, here is what an IT professional would do:

- First, they install VMware ESXi (the hypervisor, the software that runs VMs) on all 10 physical hosts.
- They install vCenter Server, which manages all the hosts as one big system.
- They create a cluster called 'Production-Cluster' and add all 10 hosts to it.
- They enable vSphere HA and set admission control to 'Reserve 20% of cluster resources'. This ensures that if one host fails, there is always enough spare capacity to restart its VMs.
- They enable DRS with a 'Fully Automated' migration mode and an 'Aggressive' threshold. This means DRS will constantly shuffle VMs between hosts to keep CPU and memory utilisation optimal.
- They enable DPM to 'Automatic' mode so that during quiet hours (late night), idle hosts are powered off, reducing electricity and cooling costs.

One day, a host's power supply fails. Here is what happens step-by-step:

1. The host goes offline.
2. HA detects the failure within a few seconds because heartbeat signals between hosts stop.
3. HA looks at the admission control reservation. It sees that 20% of total cluster resources are unused. That gives it enough space to restart all VMs from the failed host.
4. HA immediately starts restarting each VM on the remaining healthy hosts. Within minutes, all applications are back online. The retail website never went entirely down because some VMs were already on other hosts.
5. Meanwhile, DRS notices that the remaining hosts are now running more VMs and their utilisation spikes. DRS redistributes VMs among all hosts to keep load balanced.
6. The IT professional gets an alert on their phone. They replace the failed power supply and reboot the host. DPM automatically powers it back on. The host rejoins the cluster. DRS moves some VMs back to it to rebalance.

Every day, the IT professional monitors resource usage using vCenter's performance charts. They watch for 'resource contention' — when VMs are waiting for CPU or memory. If the database VM starts using 90% of its CPU consistently, they increase its shares in the resource pool so it gets priority over less critical VMs. They also check DRS recommendations daily to see if any VMs should be moved manually for specific compliance reasons.

This scenario shows that clusters are not just about failover; they are about efficiency, automation, and predictability. An IT professional spends less time fixing broken servers and more time optimising performance. The key actions they perform are: configuring admission control, setting DRS automation levels, creating resource pools, and monitoring utilisation alerts. Their tools are vSphere Client, vCenter alarms, and the esxtop command-line tool for deep performance analysis.

## Exam focus

The VCP-DCV exam tests your knowledge of resource management and clusters rigorously. Here is exactly what you need to know.

First, the exam loves to test the differences between vSphere HA, DRS, and DPM. Expect multiple-choice questions that give a scenario and ask which feature solves it. Common traps include:

- A question describes a host failure and asks for the feature that restarts VMs. Many beginners confuse this with vMotion, but vMotion moves running VMs — it does not restart them after a failure. The correct answer is HA.
- A question describes a host running at 90% CPU while another runs at 10%, and asks which feature automatically moves VMs to balance load. The correct answer is DRS, not HA.
- A question describes wanting to save power during off-peak hours. The correct answer is DPM, not DRS.

Second, the exam tests admission control policies extensively. You must memorise the three types:

- Cluster resource percentage: You specify a percentage (e.g., 20%) of total CPU and memory that is reserved for failures. It is simple to configure but can be wasteful if the percentage is too high.
- Slot policy: This is more complex. It calculates a 'slot' size based on the largest VM in the cluster. It then reserves enough slots equal to the number of host failures you want to tolerate. The trap here is that if you have one VM requiring 64 GB of memory, the slot size becomes 64 GB, which is inefficient for smaller VMs.
- Dedicated failover host: You designate one host that stays empty. This is straightforward but wastes an entire host's resources.

Third, the exam tests resource pool concepts. You need to understand shares, reservations, and limits. A typical question: 'You want to guarantee a VM always has at least 4 GB of memory. What should you configure?' The answer is a reservation. Another question: 'What prevents a VM from using more than 8 GB of memory?' The answer is a limit. The trap here is confusing shares with reservations. Shares only affect priority when there is contention — they do not guarantee resources.

Fourth, the exam asks about vMotion requirements. vMotion requires that all hosts in the cluster have compatible CPUs (same manufacturer and generation), can access the same storage (shared storage), and have a dedicated VMkernel network (a special network interface for vMotion traffic). The exam loves to ask what is NOT a requirement for vMotion — watch out for 'same version of ESXi' which is not strictly required (though recommended).

Fifth, the exam tests the concept of 'EVC mode' (Enhanced vMotion Compatibility). EVC mode creates a baseline CPU feature set that all hosts in a cluster must support. This allows you to mix different generations of the same CPU family. The exam will ask: 'You have hosts with Intel Xeon E5-2600 v3 and v4 CPUs. What should you configure to enable vMotion between them?' The answer is to enable EVC mode on the cluster and set it to the baseline that both support (e.g., Intel 'Haswell' generation).

Finally, the exam tests cluster validation. The 'Validate Cluster' wizard checks that all prerequisites for HA, DRS, and vMotion are met. The exam will ask: 'Which tool should you run before enabling HA to verify all hosts are correctly configured?' The answer is the Cluster Validation wizard.

Key definitions to memorise:

- HA: Automatically restarts VMs after host failure.
- DRS: Automatically moves VMs to balance load across hosts.
- vMotion: Zero-downtime migration of running VMs between hosts.
- DPM: Powers hosts on and off based on demand.
- Admission control: Policy that reserves resources for failover.
- Resource pool: Logical container for allocating resources.
- Shares: Relative priority when resources are contested.
- Reservation: Guaranteed minimum resource allocation.
- Limit: Maximum resource usage cap.
- EVC: Compatibility mode for vMotion across CPU generations.

## Step by step

1. **Create a Cluster** — In the vSphere Client, navigate to a data center, right-click, and select 'New Cluster'. Give it a name (e.g., Production). This creates an empty container that will hold your hosts. The cluster does nothing until you add hosts and enable features.
2. **Add Hosts to the Cluster** — Add ESXi hosts by right-clicking the cluster and selecting 'Add Host'. You must provide the host's IP address and credentials. Each host must be licensed for the features you intend to use (HA requires certain licensing). Once added, the host's resources become part of the cluster pool.
3. **Enable vSphere HA** — Edit the cluster settings and turn on vSphere HA. Configure admission control — for example, select 'Cluster resource percentage' and set it to 20%. Also configure 'VM monitoring' if you want HA to restart individual VMs that stop responding within the guest OS. This step ensures automatic failover protection.
4. **Enable DRS and Set Automation Level** — Edit the cluster settings and turn on vSphere DRS. Choose the automation level (e.g., Fully Automated) and the migration threshold (e.g., Aggressive). DRS will now continuously evaluate host utilisation and move VMs as needed to balance load. Without this, VMs would stay on the host where they started, leading to imbalance.
5. **Enable DPM (Optional)** — Edit the cluster settings and turn on vSphere DPM. Choose an automation level — Manual (recommended for beginners) or Automatic. If Automatic, DPM will power down hosts when utilisation is low. Ensure your hosts support wake-on-LAN or have out-of-band management (iLO, DRAC) so that DPM can power them back on.
6. **Create Resource Pools** — Right-click the cluster and select 'New Resource Pool'. Give it a name (e.g., Finance). Set shares (e.g., High), a reservation (e.g., 8 GB memory), and a limit (e.g., 16 GB). This divides the cluster's resources among departments, preventing one department's VMs from starving another's.
7. **Validate the Cluster Configuration** — Right-click the cluster and select 'Validate Cluster'. This wizard checks all prerequisites — network connectivity, shared storage access, time synchronisation, and CPU compatibility. Fix any errors before going into production. This step catches configuration mistakes early.

## Comparisons

### vSphere HA vs vSphere DRS

**vSphere HA:**
- Restarts VMs automatically after a host failure.
- Does not balance load; only reacts to failures.
- Requires admission control to reserve resources for failover.

**vSphere DRS:**
- Moves running VMs between hosts to balance CPU and memory load.
- Prevents resource contention before it becomes a problem.
- Uses vMotion for migrations; requires no admission control.

### Shares vs Reservation

**Shares:**
- A relative priority value (Low, Normal, High) for allocating resources when contention occurs.
- Does not guarantee any specific amount of resource; only affects distribution during competition.
- Can be changed at any time without affecting running VMs.

**Reservation:**
- A guaranteed minimum amount of CPU or memory that is always available to a VM or resource pool.
- Even if the total cluster resources are overcommitted, a reservation ensures the resource is available.
- Limits the number of VMs that can run because it commits physical resources to the reservation holder.

### Admission Control: Slot Policy vs Admission Control: Cluster Resource Percentage

**Admission Control: Slot Policy:**
- Calculates a slot based on the largest VM in the cluster.
- Reserves enough slots to tolerate a specified number of host failures.
- Can be inefficient if VMs have widely varying sizes, leading to wasted resources.

**Admission Control: Cluster Resource Percentage:**
- Reserves a fixed percentage of total cluster CPU and memory for failover.
- Simple to configure and understand.
- Does not account for individual VM sizes; may reserve too much or too little depending on VM demands.

### EVC Mode vs No EVC Mode

**EVC Mode:**
- Creates a common baseline CPU feature set across all hosts in the cluster.
- Allows vMotion between hosts of different CPU generations (e.g., Haswell and Broadwell).
- May disable advanced CPU features available on newer hosts to maintain compatibility.

**No EVC Mode:**
- Each host exposes its full native CPU feature set to VMs.
- vMotion is only possible between identical CPU generations.
- Provides maximum performance for VMs running on the newest hosts but limits live migration flexibility.

### Storage vMotion vs vMotion

**Storage vMotion:**
- Moves the virtual machine's disk files from one datastore to another while the VM is running.
- Does not require shared storage; it copies data between storage devices.
- Results in zero downtime but can take longer because it copies large disk files.

**vMotion:**
- Moves a running VM's memory and processor state from one host to another.
- Requires shared storage so that both hosts can see the same disk files.
- Completes in seconds because it only transfers memory pages, not disk data.

## Diagram

_This diagram shows the hierarchy from a data center down to a cluster, its hosts, and VMs, along with the central management role of vCenter Server controlling HA, DRS, and DPM._

```mermaid
flowchart TD
    A[Data Center] --> B[Cluster]
    B --> C[Host 1]
    B --> D[Host 2]
    B --> E[Host 3]
    C --> F[VM1]
    C --> G[VM2]
    D --> H[VM3]
    E --> I[VM4]
    B --> J[vCenter Server]
    J --> K[HA]
    J --> L[DRS]
    J --> M[DPM]
    K --> N[Restart VMs on host failure]
    L --> O[Balance VMs via vMotion]
    M --> P[Power hosts on/off based on demand]
```

## Common misconceptions

- **Misconception:** If HA restarts VMs after a host failure, the applications inside those VMs will not lose any data. **Reality:** HA restarts the VM, which is similar to a power cycle. The guest operating system and applications reboot, so any unsaved data in memory is lost. HA does not protect against data loss — it only ensures the VM comes back online quickly. (Beginners assume 'high availability' means zero data loss. They do not realise that restarting a VM is not the same as a live migration (vMotion) where data is preserved.)
- **Misconception:** vSphere DRS works independently of hardware compatibility — it can move VMs between any hosts in the cluster. **Reality:** DRS relies on vMotion to move VMs. vMotion requires that all hosts in the cluster have compatible CPUs (same manufacturer and generation, or EVC must be configured) and access to the same shared storage. Without these, DRS cannot move VMs. (People think DRS is magic. They forget that the underlying migration technology (vMotion) has strict hardware prerequisites.)
- **Misconception:** Setting a reservation on a resource pool guarantees that a VM will always perform at top speed. **Reality:** A reservation guarantees that a VM will have at least that amount of resources available, but it does not cap performance at a higher level. The VM can still use more resources if they are available. A reservation prevents starvation but does not ensure peak performance if the host is overallocated. (The word 'guarantee' is misleading. Beginners think reservation equals performance, but it only prevents outright failure due to resource exhaustion.)
- **Misconception:** A cluster can have only one resource pool. **Reality:** A cluster can have multiple resource pools, nested in a hierarchy. You can create a resource pool for each department or project, and each pool can have its own shares, reservations, and limits. This allows fine-grained control over resource allocation. (The default view shows a single 'root' resource pool for the cluster. Beginners assume you cannot create additional pools, but you can create as many as you need.)
- **Misconception:** vSphere DPM can power down any host in the cluster, including the host running the vCenter Server appliance. **Reality:** DPM will not power down a host that is essential for cluster operations, such as the host where vCenter Server is running. DPM only powers down hosts that are deemed unnecessary based on current resource demand, and it avoids powering down hosts that run critical VMs unless they can be migrated away first. (This misconception comes from oversimplifying DPM. Beginners think DPM is reckless, but it is designed to be safe.)
- **Misconception:** Admission control is optional for HA to function. **Reality:** Admission control is disabled by default, but if you disable it, HA cannot guarantee that it has enough resources to restart VMs after a failure. The cluster will still attempt to restart VMs even without admission control, but it may fail if resources are insufficient. For production environments, admission control should always be enabled. (The default setting is 'disabled'. Beginners assume defaults are safe, but the exam expects you to know that disabling admission control is risky.)

## Key takeaways

- A vSphere cluster turns multiple physical hosts into a single logical resource pool, enabling features like HA, DRS, and DPM to automate failover and load balancing.
- vSphere HA automatically restarts virtual machines on healthy hosts when a host fails, but it does not prevent data loss from applications running inside those VMs.
- DRS uses vMotion to move running VMs between hosts with zero downtime, but requires CPU compatibility and shared storage across all hosts in the cluster.
- Admission control ensures that HA has reserved capacity to restart VMs after a failure; the three policies are cluster resource percentage, slot policy, and dedicated failover host.
- Resource pools allow you to allocate shares, reservations, and limits to groups of VMs, controlling how CPU and memory are distributed among business units.
- EVC mode normalises CPU feature sets across hosts of different generations, enabling vMotion between them without losing advanced processor features.

## FAQ

**What is the difference between vSphere HA and vMotion?**

vSphere HA restarts virtual machines after a host failure — it handles crashes. vMotion moves running virtual machines between hosts with zero downtime — it handles planned maintenance. They serve different purposes.

**Can I use DRS without HA or vice versa?**

Yes. DRS and HA are independent features. You can enable DRS without HA to balance load without failover protection, or enable HA without DRS to get automatic restarts without load balancing. However, it is best practice to enable both for a resilient cluster.

**What happens if all hosts in a cluster run out of memory?**

VMs that exceed their configured memory limit will experience swapping or ballooning (the VMkernel forces them to release memory). If no memory is available and limits are not set, vSphere can use memory overcommitment — it allows more VMs to run than physical memory exists, relying on the fact that VMs do not always use their full allocation. If too many VMs request memory simultaneously, the hypervisor will swap to disk, which severely degrades performance.

**What is a slot in admission control?**

A slot is a unit of resource allocation computed by the slot policy. It is based on the largest virtual machine in the cluster. For example, if the largest VM requires 2 vCPUs and 4 GB of RAM, each slot has those resources. The cluster reserves enough slots to handle a host failure, which can be inefficient if your VMs vary widely in size.

**Why does vMotion require shared storage?**

vMotion moves the running state of a VM from one host to another, but the actual virtual disk files (where the operating system and data are stored) must be accessible by both hosts simultaneously. Shared storage — like a SAN or a NAS — provides this common access. Without shared storage, vMotion would require copying the entire disk, which is called Storage vMotion.

**What is the difference between a reservation and a limit in a resource pool?**

A reservation guarantees that a VM or resource pool will always have at least that amount of resources available — it is a floor. A limit caps the maximum resources a VM or pool can consume — it is a ceiling. They are independent settings; you can set both on the same object.

**Can I change the DRS automation level after creating the cluster?**

Yes. You can edit the cluster settings at any time to change DRS automation from Fully Automated to Manual or vice versa. You can also set individual VMs to a different automation level than the cluster default. The change takes effect immediately.

## Check your understanding

1. **Which cluster feature automatically restarts virtual machines after a physical host failure?**

   Answer: vSphere High Availability (HA).

2. **What is the purpose of admission control in a vSphere HA cluster?**

   Answer: Admission control reserves a portion of cluster resources so that there is always enough capacity to restart VMs if a host fails.

3. **You have three hosts with Intel Xeon E5-2600 v3 CPUs and one host with v4 CPUs. To allow vMotion between all hosts, what must you configure?**

   Answer: You must enable Enhanced vMotion Compatibility (EVC) mode on the cluster and set it to a baseline supported by both CPU generations (e.g., Intel 'Haswell').

4. **What is the difference between a resource pool reservation and a resource pool limit?**

   Answer: A reservation guarantees a minimum amount of resources, while a limit caps the maximum amount of resources that can be used.

5. **Which cluster feature can automatically power off underused hosts during periods of low demand?**

   Answer: vSphere Distributed Power Management (DPM).

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/vmware-vcp-dcv/resource-management-and-clusters