Does DRS always act automatically?

DRS should not be read as unlimited automatic balancing. It works within configured policy and safety conditions, and its behavior is validated for each deployed configuration.

Does DRS use live migration?

Live migration is a separate capability used in supported maintenance and balancing scenarios. It requires compatible source and destination hosts, capacity, network continuity, storage access and cluster eligibility.

How are unsafe moves prevented?

Host eligibility, destination compatibility, network and storage access, quorum state and placement rules are checked. If a precondition is not met, the action is blocked or restricted.

How can we validate DRS for our environment?

Run the recommended scenarios in a technical POC with your own hosts and representative workloads, and review the results and audit events in Lejam.

Lejam · DRS

How Lejam DRS Makes Placement Decisions

Lejam DRS uses current cluster state and configured policy to make workload-placement and resource-balancing decisions. Its inputs include resource eligibility, placement rules, CPU and memory pressure across eligible hosts, host health and recent failures, and cluster quorum and reachability. It is policy-driven placement within those limits, not unlimited automatic optimization.

Decision inputs

Input	What it affects
Resource state and VM eligibility	Only workloads and resources that are enabled and eligible are considered for placement or balancing.
Constraints: affinity, anti-affinity and placement rules	Where configured, rules decide which hosts a workload may share or must avoid, and narrow the set of valid destinations.
CPU pressure	Indicates which eligible hosts have less processing headroom, influencing where new or moved workloads are placed.
Memory pressure	Indicates which eligible hosts have less memory headroom, influencing placement and balancing choices.
Host health and recent failures	Hosts with a recent failure state or that are not eligible are excluded or deprioritized as destinations.
Quorum and reachability	Placement actions depend on a healthy cluster view. Without quorum or reliable reachability, actions are restricted.

Decision flow

1
Collect current cluster state
Resource state, host health, utilization and cluster membership.
2
Filter eligible hosts
Hosts that are unhealthy, unreachable or ineligible are removed from consideration.
3
Apply placement constraints
Configured affinity, anti-affinity and placement rules narrow the valid destinations.
4
Evaluate resource pressure and capacity
CPU and memory pressure and available capacity are compared across the remaining hosts.
5
Identify a placement or balancing action
An eligible destination is selected for a new workload, or a balancing action is identified, according to the configured policy.
6
Validate movement prerequisites
Before any migration proceeds, source, destination, network, storage and cluster conditions are checked.

Safety guardrails

When a precondition is not met, the action is blocked or restricted. DRS does not override these conditions.

Host eligibility: the destination must be eligible and healthy
Destination compatibility: compatible CPU and sufficient capacity
Network reachability and continuity between source and destination
Storage access appropriate to the cluster design
Cluster and quorum state
Configured placement rules
For HA restart on shared resources, fencing is required before a safe restart

Migration behavior

Live migration is a separate Lejam capability that DRS can rely on in supported maintenance and balancing scenarios. It is not a guarantee that every imbalance results in a move.

A live migration depends on the source VM running with accessible memory state, network and storage; a destination with compatible CPU, capacity, network reachability, storage access and cluster eligibility; and network continuity during the move. Plan maintenance windows and application expectations accordingly rather than assuming zero downtime.

What is not published

Internal scoring weights, numeric thresholds, hysteresis and cooldown values, and implementation internals are not published on this website. Evaluating teams validate DRS behavior against their own clusters and workloads during a technical POC.

Validation evidence

VirtuWa's Engineering Validation states that Distributed Resource Scheduling has been validated for workload placement and resource-balancing scenarios across managed virtualization hosts.

Read the Engineering Validation scope Validate scenarios in a technical POC

Recommended POC tests

Place a new VM while hosts carry different utilization
Check affinity, anti-affinity or placement rule behavior where configured
Mark a host ineligible or simulate a failure state and observe placement
Create a CPU and memory pressure scenario and observe balancing
Verify live migration prerequisites and the migration result
Test behavior when quorum or reachability is degraded
Review DRS events and audit visibility in Lejam

Frequently asked questions

Resource and VM eligibility, configured affinity, anti-affinity and placement rules, CPU and memory pressure across eligible hosts, host health and recent failure state, and cluster quorum and reachability.