DRS & High Availability
Cockpit includes two features that work quietly in the background to keep your environment healthy:
- Distributed Resource Scheduler (DRS) keeps your physical hosts evenly loaded, so no single host becomes a bottleneck while others sit idle.
- High Availability (HA) restarts your virtual machines on another host if the host they were running on fails.
Together they help your workloads stay fast and stay online with little day-to-day effort from you.
Distributed Resource Scheduler (DRS)
DRS continuously watches CPU and memory usage across the hosts in your cluster. When one host becomes busier than the others, DRS can move running virtual machines to a less-loaded host — with no downtime — to even things out.
How aggressively should it balance?
You choose how eager DRS is to move workloads using a single Migration Threshold slider, from Conservative to Aggressive:
| Setting | Behavior |
|---|---|
| Conservative | Only rebalances when a host is heavily and persistently loaded. Fewest migrations. |
| Balanced (default) | A sensible middle ground for most environments. |
| Aggressive | Reacts to even small imbalances. Keeps hosts very evenly loaded, at the cost of more frequent migrations. |
Start with Balanced. Move toward Conservative if you prefer fewer migrations, or toward Aggressive if you want the tightest balancing.
How much control do you want?
DRS offers three automation levels:
- Fully Automated — DRS moves workloads by itself whenever it detects an imbalance. Set it and forget it.
- Partially Automated — DRS does the analysis but does not act on its own. It posts recommendations in the Tasks panel, and you decide whether to apply them.
- Manual — Automatic balancing is off. You move workloads yourself when you choose to. (The threshold slider is disabled in this mode.)
Per-VM overrides
Sometimes you want most of the cluster balanced automatically, but a few specific VMs left exactly where they are — for example a latency-sensitive database you never want moved unexpectedly.
You can give an individual VM its own automation level that overrides the cluster setting. For instance, keep the cluster Fully Automated but set one critical VM to Manual so DRS never relocates it on its own.
You can set this override in two places, and they always stay in sync because they share the same setting:
- From the DRS overrides list on the cluster's Configure tab.
- From the individual VM's settings.
What DRS can and cannot move
::: important DRS moves compute only — the running memory and CPU state of a VM travel to the new host, but the VM's disk stays where it is. Because of this, a VM is only eligible for automatic balancing if all of its disks live on a shared datastore (storage that every host can reach, such as NFS or a clustered datastore).
A VM with disks on local, host-only storage is skipped by DRS, because moving its disk would be too slow to do automatically. See Storage & Datastores for more on shared storage. :::
High Availability (HA)
HA protects your VMs against a host crash. When enabled, Cockpit watches each host's heartbeat. If a host stops responding, Cockpit automatically restarts that host's VMs on the remaining healthy hosts, so services come back without waiting for the failed host to be repaired.
Settings
- Enable HA — Turns the protection on or off for the cluster.
- Failover Delay — How long Cockpit waits (for example, 15 seconds) after a host stops responding before it starts restarting that host's VMs elsewhere. This short pause avoids acting on a brief network blip and prevents a VM from accidentally running in two places at once.
TIP
HA restarts VMs on another host, which means those VMs must be on shared storage for the surviving host to access their disks. Pair HA with shared datastores for the best protection.
Keeping critical services spread out
For services that run as a group — such as the three control-plane nodes of a High-Availability Kubernetes cluster — Cockpit uses anti-affinity to keep the members apart:
- When the VMs are first created, they are placed on three different physical hosts.
- If a host fails, HA restarts the affected member on a surviving host that is not already running another member of the group.
This ensures that no single host failure can take down more than one member at a time, preserving the group's ability to stay online.
Related topics
- Kubernetes Provisioner — HA control planes and node placement build on DRS and anti-affinity.
- Storage & Datastores — shared storage is what makes live migration and HA restarts possible.