TLDR: In Oct 2026, we want to announce TP for:

• Day-2 upgrade/update without an external registry

OCP feature name: NoRegistryClusterUpgrade

Installation and upgrade processes for the OpenShift Virtualization Engine (OVE) has been identified as a critical area for improvement to address customer concerns regarding its complexity compared to competitors like VMware, Nutanix, and Proxmox. Customers often struggle with disconnected environments, operator configuration, and managing external dependencies, making the initial deployment challenging and time-consuming. 

To resolve these issues, the goal is to deliver a streamlined, opinionated upgrade workflow that leverages existing tools like the Agent-Based Installer, the Assisted Installer, and the OpenShift Appliance (all sharing the same underlying technology) while pre-configuring essential operators and minimizing dependencies, especially the need for an image registry before upgrade.

Additionally, the offered functionality has to cover Day-1 (install) and Day-2 (adding new nodes) in a disconnected and (external) registryless environment. This use case is addressed by OCPSTRAT-2251.

By focusing on enterprise customers, particularly VMware administrators working in isolated networks, this effort aims to provide a user-friendly upgrade experience that simplifies cluster setup and ensures quick time-to-value.

Objectives and Goals

Primary Objectives

• Simplify the OpenShift Virtualization Day-2 (upgrade) processes to reduce complexity for enterprise customers coming from VMware vSphere.
• Enable upgrade in disconnected environments with minimal prerequisites.
• Eliminate the dependency on a pre-existing image registry in disconnected upgrades.
• Provide a user-friendly, UI-based upgrade experience for users used to VMware vSphere.

Goals

• Deliver an upgrade experience leveraging existing tools like the Agent-Based Installer, Assisted Installer, and OpenShift Appliance, i.e. the Assisted Service.
• Pre-configure essential operators for OVE and minimize external day 2 dependencies  
• Ensure successful upgrade in disconnected environments with standalone OpenShift, with minimal requirements and no pre-existing registry

Personas

Primary Audience 

VMware administrators transitioning to OpenShift Virtualization in isolated/disconnected environments.

Pain Points

• Lack of UI-driven workflows; writing YAML files is a barrier for the target user (virtualization platforms admins)
• Complex setup requirements (e.g., image registries in disconnected environments)

Technical Requirements

Use case:

OpenShift upgrade with WebUI in a disconnected environment without a local image registry (all necessary components (RHCOS, OpenShift, and selected Day-2 operators) are a part of the mounted ISO image) for all Openshift deployments deployments:

• Single Node OpenShift,
• 3-Node with additional worker nodes
• Standard OpenShift cluster with dedicated control plane nodes

Additionally, support for x86_64 architecture (Aarch64, S390 and IBM-Z can be delivered as separate features after GA).

Use case:

• Agent Installer for OCP-Virt for Day-2 upgrade

Image Registry Simplification

• Eliminate the dependency on an existing external image registry for disconnected environments.
• Support a workflow similar to the OpenShift Appliance model, where users can deploy a cluster without external dependencies.

Agent-Based Installer Enhancements

• Extend the existing UI to capture all essential data points (e.g., cluster details, network settings, storage configuration) without requiring YAML files.
• List of Operators:
  • OpenShift Virtualization Operator
  • Node Health Check (NHC) Operator
  • Fence Agents Remediation (FAR) Operator
  • Node Maintenance Operator (NMO)
  • Loki
  • OpenShift Logging Operator
  • Cluster Observability Operator(COO)
  • MetalLB
  • Migration Toolkit for Virtualization (MTV)
  • Kube Descheduler Operator
  • NUMA Resources Operator
  • NMState Operator
  • OADP

User experience requirements

The first area of focus is a disconnected environment. We target these environments with the Agent-Based Installer. 

The current docs for installing on disconnected environment are very long and hard to follow.

Connected phase

Assumption: The same ISO provided by functionality defined in OCPSTRAT-2251 will be used during upgrade.

• It will be a new option in the Assisted Installer wizard.
• Selecting the new option, a user will receive a simple wizard leading to a customized ISO download.
• ISO will be generated upfront for each Z-release with the latest version of Day-2 operators:
  • Minimum x86_64 architecture

Disconnected phase

• IUpgrade/update:

• • This may require an intermediate step to update the cluster from 4.Y.Z to 4.Y.Z’, where Z’ is a recommended release for upgrading from Y to Y+1 release (e.g. 4.20.5 -> 4.20.25 -> 4.21.3)
  • Delivering this functionality in a disconnected and registerless environment may require more than one OpenShift release cycle.
  • Update from one Z-release to another under the same Y-release (e.g. 4.20.5 -> 4.20.10)
  • Upgrade from Y-release to Y+1-release
  • Upgrade/Update without an external registry
    • Infrastructure
    • OLM operators

Definition of done

• Functionality described above delivered, tested by QE, and documented.

Open question

Out of scope

• Shared storage solution which should be provided by a customer

Links:

• Agent-Installer Installation UI for OpenShift Virtualization - update
• Simplified Disconnected Installation
• This document written by Zane Bitter as the Staff Engineer of this area contains an interactive workflow proposal.

• PRD Installation UX for OpenShift Virtualization (and notes from regular meetings)