Organizations across higher education and enterprise sectors face rising virtualization costs, shifting licensing structures, and architectural decisions that can no longer be deferred. In this landscape, IT leaders need a low-disruption migration path that protects critical workloads today while establishing a modern, hybrid cloud foundation for the future.

At Red Hat Summit 2026, Joseph Seegmiller, Infrastructure Engineer at Brigham Young University, joined Red Hat Solution Architects John Quigley and John Call to address these exact challenges. By using Red Hat OpenShift to run virtual machines (VMs) and containers side by side, Brigham Young University consolidated its infrastructure and simplified its operations.

We ended up deciding to move all of our virtualization into Red Hat OpenShift Virtualization. We migrated 1,500 virtual machines in only 6 weeks.

Joseph Seegmiller

Infrastructure Engineer, Brigham Young University

Joseph Seegmiller, Infrastructure Engineer at Brigham Young University, joined Red Hat Solution Architects John Quigley and John Call on stage.

Figure 1. Joseph Seegmiller, Infrastructure Engineer at Brigham Young University, joined Red Hat Solution Architects John Quigley and John Call on stage.

While rapid migration is a significant milestone, maintaining high availability and protecting stateful database workloads after landing on the new platform is the top priority for infrastructure teams.

The underlying risk of data corruption in shared storage environments

To build a resilient platform, IT leaders must understand how Red Hat OpenShift handles node failures differently than traditional hypervisors. By default, when a node running VMs or containerized workloads becomes unresponsive, it does not instantly reschedule the affected workloads. This delay is an intentional safety feature designed to protect data integrity.

In a shared storage environment, a split-brain scenario poses a major threat. If a node loses communication with the cluster control plane but remains powered on, it may still write data to disk.

If a node loses network connectivity but its Fibre Channel connection remains active, the virtual machines continue running and writing to disk. Rescheduling that virtual machine automatically on a new node mounts the disk twice, causing severe data corruption. This is why automated node rebooting and fencing are required.

Joseph Seegmiller

Infrastructure Engineer, Brigham Young University

Without automated remediation, resolving these failures requires manual intervention. An operator must verify that the failed node is completely offline before safely terminating the old VM instance and starting a new one. In a large environment, this manual process introduces significant recovery delays.

The outage turned our operations team's dashboards into a Christmas tree with a bunch of blinking lights. It took us 2 hours to resolve. Had we implemented these node remediation strategies, the system would have resolved the issue in minutes instead of hours.

Joseph Seegmiller

Infrastructure Engineer, Brigham Young University

Automated recovery in minutes with Medik8s

To eliminate manual remediation and reduce downtime from hours to minutes, Red Hat OpenShift integrates the Medik8s operator framework. This framework provides automated node remediation and high availability for workloads including VMs.

The automated recovery process operates through 3 distinct components:

  1. Node Health Check operator: This component acts as a cluster smoke detector. It continuously monitors the status of worker nodes. If a node reports a NotReady or Unknown condition for the length of a configured duration (60 seconds is typical), the operator sounds an alarm and triggers a remediation template.
  2. Fence Agents Remediation (FAR): This is the fastest power-based fencing method. It interacts directly with the physical hardware's Baseboard Management Controller (BMC) interfaces, such as Dell iDRAC or HPE iLO, using the common Redfish API. The agent commands the BMC to reboot the hardware. Once the BMC confirms the power cycle, the cluster safely deletes the stuck VM and container workloads and reschedules them on healthy nodes, completing the process in approximately 155 seconds.
  3. Self Node Remediation (SNR): Serving as a reliable software-based fallback, this agent uses a kernel-level watchdog. The agent must interact with the watchdog timer every 30 seconds. If the agent detects that the node is isolated from its peers and the API server, it stops resetting the watchdog timer (or petting the watchdog in system administrator jargon). The watchdog then times out and forces the local operating system to reboot itself, safely releasing its storage locks.

By deploying these strategies, infrastructure teams protect VMs against data corruption while recovering automatically without human intervention.

Rebalancing live workloads using actual resource pressure

Achieving high availability requires more than surviving node crashes. It also requires proactive workload distribution to prevent nodes from running out of resources.

The default Kubernetes scheduler only evaluates resource placement decisions at the initial startup of a VM. Over time, as users log in or run intensive tasks, certain VMs may use more resources than initially requested, leading to resource starvation on specific nodes.

To resolve this imbalance, the Descheduler operator periodically evaluates the cluster. Instead of relying solely on static, pre-allocated resource requests, the Descheduler can leverage real-time resource consumption data provided by the kernel's Pressure Stall Information (PSI) interface.

PSI metrics track the amount of time VMs or containers spend waiting for CPU, memory, or disk (I/O) resources. If the Descheduler detects a node experiencing resource pressure, it identifies eligible VMs and initiates a live migration to move them to underutilized nodes. This proactive rebalancing maintains consistent application performance across the entire fleet.

Modernize your infrastructure strategy

Migrating to a unified hybrid cloud application platform helps organizations control operational costs, eliminate infrastructure silos, and establish a secure environment for modern application development. By combining Red Hat OpenShift Virtualization with automated remediation and proactive workload rebalancing, IT leaders can deliver predictable high availability for their most critical workloads.

Take the next step in your virtualization modernization journey:

Ressource

15 Gründe für die Einführung von Red Hat OpenShift Virtualization

Discover how Red Hat OpenShift Virtualization can unify and simplify your IT operations, using one platform for both virtual machines and containers.

Über den Autor

Debbie Margulies is a principal product marketing manager for Red Hat OpenShift and has been at Red Hat since 2019 through the acquisition of StackRox.

UI_Icon-Red_Hat-Close-A-Black-RGB

Nach Thema durchsuchen

automation icon

Automatisierung

Das Neueste zum Thema IT-Automatisierung für Technologien, Teams und Umgebungen

AI icon

Künstliche Intelligenz

Erfahren Sie das Neueste von den Plattformen, die es Kunden ermöglichen, KI-Workloads beliebig auszuführen

open hybrid cloud icon

Open Hybrid Cloud

Erfahren Sie, wie wir eine flexiblere Zukunft mit Hybrid Clouds schaffen.

security icon

Sicherheit

Erfahren Sie, wie wir Risiken in verschiedenen Umgebungen und Technologien reduzieren

edge icon

Edge Computing

Erfahren Sie das Neueste von den Plattformen, die die Operations am Edge vereinfachen

Infrastructure icon

Infrastruktur

Erfahren Sie das Neueste von der weltweit führenden Linux-Plattform für Unternehmen

application development icon

Anwendungen

Entdecken Sie unsere Lösungen für komplexe Herausforderungen bei Anwendungen

Virtualization icon

Virtualisierung

Erfahren Sie das Neueste über die Virtualisierung von Workloads in Cloud- oder On-Premise-Umgebungen