Your Oracle estate is running on 3 “clocks" you don’t control: The hypervisor renewal arrived with a higher cost nobody budgeted for. The database support window has a date on it. And somewhere above you, someone has committed the company to AI that must rely on the critical data that lives in those databases. Each timeline belongs to a different vendor and is being used to force a decision on someone else's schedule.

The work Red Hat and Everpure have done together exists to break that coupling. Every layer of the estate—hypervisor, operating system (OS), storage, and the database itself—should modernize on its own timeline, which you control. Over the past 2 years we’ve built and published the validation to make that real for Oracle workloads specifically. This post covers what we tested, what the results were, and what they mean for how you sequence the next 3 years.

Validating Oracle workloads on Red Hat OpenShift Virtualization and Everpure

Red Hat's engineering team published a complete reference architecture for Oracle Database 19c on Red Hat OpenShift Virtualization, covering single instance and Oracle Real Application Clusters (RAC), with the full test artifacts available on GitHub. The validation ran functionality, performance, scalability, and live migration testing. The storage under those tests included Everpure FlashArray provisioned through the Portworx Enterprise operator.

Two results matter most for anyone planning a migration:

  1. Live migration of a virtual machine (VM) running a single-instance Oracle Database completed in 1-2 minutes on average, and the result held whether the database was idle or under production-like load, with virtual users generating sustained volumes of concurrent transactions. Live migration is the operation that makes a virtualization platform livable. Node maintenance, rebalancing, and hardware refresh all depend on it, and it works for Oracle on this platform the way you need it to.
  2. The support posture is the same one you already operate under. Oracle certifies to the OS inside the VM, not to the hypervisor beneath it. Oracle Database on Red Hat Enterprise Linux (RHEL) remains a fully supported OS configuration, and Red Hat has published comprehensive, validated reference architectures for running these workloads—including RAC—on OpenShift Virtualization

3 postures, 1 platform

Customers come to this work from different starting positions. The platform doesn’t force them into the same path.

  • Keeping the estate on premise and exiting the legacy virtualization platform. This is the posture the renewal letter creates. Instead of being locked in to a prohibitive hypervisor renewal, Red Hat’s migration toolkit for virtualization moves Oracle VMs from VMware vSphere to OpenShift Virtualization without needing the administrator to modify the guest. The database administrator's environment on Monday looks like it did on Friday. FlashArray sits underneath both the old platform and the new one, and ActiveCluster can move the storage between arrays without taking the database down, which means the storage layer never blocks the migration window. The database didn’t move. The platform around it did.
  • Modernizing on the database's own clock. Oracle's upgrade cycle is its own forcing function, and an upgrade rehearsed badly is the most expensive kind of outage. Array snapshots give you instant, space-efficient clones of production for dev, test, and performance environments, so the rehearsal runs against real data without a 2nd copy of the storage bill. FlashBlade restores at up to 65 TB per hour, so the rollback path is measured in minutes rather than in a weekend. The platform migration and the database upgrade stop competing for the same change window because neither one depends on the other.
  • Building around the database. New services land as containers now. The question is whether they land on the same platform as the estate or on a 2nd one with its own storage, backup, and on-call rotation. Everpure serves persistent storage to both the VMs and the containers from 1 plane, on the same arrays. The team that runs the VM estate and the team that’s shipping containerized services stop maintaining parallel infrastructure. And the eventual AI workloads—including the vector and retrieval capabilities arriving in the current generation of Oracle Database—inherit the same substrate rather than demanding a new one.

Value of the storage layer

A platform migration is a sequence of moments where data has to be in 2 places, or has to move without stopping, or has to be recoverable faster than the business notices. Those are storage properties. The Red Hat validation results on RAC made the point empirically: External enterprise array storage outperformed hyperconverged alternatives for the most demanding configurations. The seams in a modernization—between hypervisors, between database versions, and between VM and container—are exactly where the storage platform either decouples the clocks or chains them back together.

Evergreen architecture extends the same logic to the storage itself. The array under your Oracle estate upgrades nondisruptively across controller generations, which removes the 1 clock infrastructure teams traditionally imposed on everyone else: the forklift refresh.

What to do with this

Start with the seam that has a date on it. If that date is a hypervisor renewal, run Red Hat’s migration toolkit for virtualization against a nonproduction Oracle VM and measure the result against the published reference architecture. If that date is a database support window, build the rehearsal environment from snapshots this quarter and time your restore path. Both exercises cost days, and both convert an external deadline into a measured plan.

The estate you run in 2029 will not look like the one you run today. The work above means you get to decide the order in which it changes.

Reference architecture, test artifacts, and configuration guidance:

Product trial

Red Hat OpenShift Virtualization Engine | Product Trial

A streamlined, dedicated solution to deploy, manage, and scale virtual machines.

About the authors

UI_Icon-Red_Hat-Close-A-Black-RGB

Browse by channel

automation icon

Automation

The latest on IT automation for tech, teams, and environments

AI icon

Artificial intelligence

Updates on the platforms that free customers to run AI workloads anywhere

open hybrid cloud icon

Open hybrid cloud

Explore how we build a more flexible future with hybrid cloud

security icon

Security

The latest on how we reduce risks across environments and technologies

edge icon

Edge computing

Updates on the platforms that simplify operations at the edge

Infrastructure icon

Infrastructure

The latest on the world’s leading enterprise Linux platform

application development icon

Applications

Inside our solutions to the toughest application challenges

Virtualization icon

Virtualization

The future of enterprise virtualization for your workloads on-premise or across clouds