OpenShift Virtualization’s memory-density model reaches from guest pages to live migration

Red Hat has published a full-stack account of how OpenShift Virtualization moves from static memory reservations toward utilization-based virtual-machine placement. The central lesson is that memory overcommit is not an isolated scheduler setting: safe density depends on coordinated behavior from the guest kernel through the hypervisor, Linux reclaim, Kubernetes accounting and cluster-level live migration.

From reservations to actual use

OpenShift Virtualization remains conservative by default, requesting memory for a VM on a 1:1 basis with its assigned guest RAM. Red Hat argues that this leaves capacity unused because many VMs consume only a fraction of their configured memory outside peak conditions.

The first layer of a denser design is guest-cooperative reclamation. Free page reporting, enabled by default, lets a guest kernel tell the hypervisor which pages it has already released so the host can return them to its allocation pool. Where guests cannot report free pages, OpenShift can deduplicate zero-filled pages with a constrained form of kernel same-page merging. Hugepage-backed VMs are the exception: their pinned memory bypasses these reclaim mechanisms to protect latency-sensitive workloads.

Since OpenShift Virtualization 4.18, multi-generational least-recently-used memory reclamation has been the default mechanism for identifying colder pages. Red Hat says MGLRU reduces broad scanning, protects active working sets and gives each VM’s control group its own generations for more targeted reclaim.

The cluster has to see pressure

Lowering VM memory requests allows the scheduler to pack more workloads onto a node, but it also makes the scheduler’s accounting less representative of possible peak demand. Red Hat’s design therefore treats local swapping or faster secondary storage as a buffer, not the complete answer.

With the KubeVirtRelieveAndMigrate descheduler strategy, OpenShift can consider real-time CPU and active-memory use. When cluster utilization becomes highly saturated, the strategy shifts toward pressure stall information, which measures time workloads spend waiting on memory operations. The descheduler can then live-migrate VMs away from pressured nodes while using asymmetric thresholds and soft taints to discourage migration churn and avoid placing new work on already stressed systems.

What operators should take away

A higher overcommit ratio is only the visible policy knob. The safety case comes from free-page reporting, MGLRU, secondary memory tiers, node-pressure protection, PSI-aware balancing and tested live-migration capacity working together.

Red Hat also describes Virtualization Platform Autopilot as a configuration tool that calculates and applies relevant reclaim, control-group and descheduler settings. It does not itself watch workloads or initiate migrations. Operators evaluating denser consolidation should validate guest support, hugepage exceptions, storage latency, migration budgets and correlated peak demand before changing the default reservation model.