On November 9, 2026, at KubeCon + CloudNativeCon NA, Red Hat announced the general availability of OpenShift 5. It is a major release and, most importantly for anyone already running OpenShift 4, it arrives as an in-place update: no cluster migration and no reinstall.
The update from OpenShift 4 to 5 is in-place: the same cluster, with the same workloads.
The platform in three ideas
- Intelligent: OpenShift Lightspeed evolves from an assistant into an agent. It helps diagnose problems, assesses the risk of each update, and always leaves approval in the hands of a person. The MCP server also arrives, so AI tools can query the cluster with RBAC and read-only access by default.
- Secure: post-quantum cryptography (ML-KEM) in the control plane, centralized TLS configuration, and encryption of data in use for AI workloads.
- Predictable: major releases every three years and one extended life cycle release per year, with up to five years of support. It is built on Kubernetes 1.36.
What changes for virtualization
Red Hat presents OpenShift 5 as a platform to run VMs, containers and AI workloads side by side. These are the OpenShift Virtualization updates that caught my eye:
Simpler operations. Native VM templates arrive (GA): save a VM you already trust and reuse it as a template, instead of rebuilding the configuration from scratch. Advanced VM search and Autopilot, which applies recommended configurations to the cluster, complete the picture.
Better use of your nodes. The descheduler now balances by memory utilization (GA), not only by CPU: when a node is under memory pressure, it redistributes VMs using live migration. OpenShift SWAP helps with memory density.
When a node runs hot on memory, the descheduler live-migrates a VM to one with more headroom.
Storage-agnostic incremental backup. Incremental backup with QEMU CBT appears (Technology Preview), and VolumeGroup Snapshots reach GA. It is not a final feature yet, but it points to shorter backup windows and less storage consumed, and it is worth watching if you protect VMs with a backup tool.
Networking without NAT. The OpenShift BGP Cloud Connector advertises the cluster's user-defined network prefixes so servers and clouds can reach VMs directly by their IP, with no NAT or proxies. The VM keeps its IP during live migration and IP-based firewall policies stay valid, which matters a lot when you migrate workloads such as Windows and Active Directory. In 5.0 it is available for ROSA HCP and ARO, with more clouds to follow. There is also OVS-DPDK (Developer Preview) for low-latency networking.
The cluster advertises its network over BGP and outside systems reach the VM directly, with its original IP. Addresses are illustrative.
Security and agents. RHEL 10 and post-quantum cryptography support stand out, along with Windows security features such as VBS and Credential Guard. The MCP server also includes a virtualization toolset (Technology Preview), so an agent can query VM resources with read-only permissions by default.
Migration from other platforms. Migration Toolkit for Virtualization (MTV) 2.12 adds a Hyper-V provider in Technology Preview, meant for starting to test direct migration paths into OpenShift Virtualization. It is not yet recommended for production.
New High availability. Besides FAR & SNR, the Storage Based Remediation operator, part of Workload Availability for Red Hat OpenShift, automatically remediates nodes that stop responding and uses shared storage for fencing operations. Check the documentation for its status and storage requirements before planning.
Conceptual illustration: a node stops responding, is fenced, and its VMs restart on healthy nodes.
My take
OpenShift 5 arrives with a longer life cycle, an update that needs no migration, and a network that respects existing IPs. On the data protection side, I will be watching how incremental backup with QEMU CBT evolves.
On security, three things stand out to me for regulated environments:
- RHCOS 10 and post-quantum cryptography. OpenShift 5 adds support for RHCOS 10, the node operating system based on RHEL 10, and keeps RHCOS 9 alongside it, so the update can be gradual. In the control plane it uses ML-KEM by default, a quantum-resistant key exchange, as a defense against "harvest now, decrypt later": someone capturing encrypted traffic today to decrypt it once that capability exists. It protects the cluster's own communication; your applications' traffic is a different path.
- A smaller attack surface. TLS configuration is centralized and enforced: a single profile for the whole platform. There are also network policies in the control plane namespaces to limit lateral movement.
- Multi-tenancy, certificates and disconnected environments. Stronger network isolation for sovereign deployments, extended certificate management and native support for disconnected installs, which weighs heavily in regulated environments.
As always, the status of each feature (GA, Tech Preview or Developer Preview) can change, so check the release notes before planning.