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 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. 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. Without automated remediation, resolving these failures requires manual intervention.