1. Proposed title of this feature request

Cloud Provider Kubevirt

2. What is the nature and description of the request?

Provide a full VM-based IPI architecture, equivalent to today’s vSphere IPI experience, for OCP-on-OCP (OpenShift Virtualization / KubeVirt) running on an OCP bare-metal cluster, including:

• Native, supported infrastructure provider integration for OCP-V, similar to vSphere/AWS/Azure.
• Cluster API and autoscaling support for guest clusters running as KubeVirt VMs.
• First-class storage integration using KubeVirt CSI on top of the bare-metal storage stack, without requiring HCP.

Goal: Customers should be able to deploy full VM-based OpenShift clusters on OpenShift Virtualization via IPI, with storage and lifecycle capabilities on par with existing vSphere IPI deployments—without being forced into Hosted Control Planes or custom “platform: none” automation.

3. Why does the customer need this? (List the business requirements here)

Today, OpenShift ACM/IPI supports cloud providers such as:

• VMware vSphere
• AWS
• Azure
• Oracle Cloud

For these platforms, IPI does more than just create VMs. It also delivers:

• Cluster API–driven lifecycle management
• Integrated autoscaling
• Native storage integration with the underlying infrastructure provider

This full-stack automation is available out of the box for vSphere, AWS, Azure, etc.

However, for full VM-based OCP on OCP-V (KubeVirt/OpenShift Virtualization):
The supported infrastructure provider options do not include Red Hat Virtualization (RHV / its successor stack) in an equivalent way.

Customers are effectively pushed towards Hosted Control Planes (HCP) when they want to run OCP on top of OCP.

If Red Hat intends to position Red Hat Virtualization / OpenShift Virtualization as a first-class alternative to other virtualization platforms, there should be a 1:1 IPI architecture comparable to vSphere IPI, rather than forcing an architectural shift to HCP.

Problems with the Current Approach

• Hosted Control Planes as a “workaround”
• Hosted Control Planes are offered as the current answer for OCP-on-OCP.
• HCP is not a standard upstream Kubernetes deployment model.
• Concentrating many clusters’ control planes into a single failure domain increases availability risk for customers.
• Some customers explicitly want full VM-based clusters, not HCP, for operational and risk-management reasons.
• “platform: none” for full VM is insufficient

Full VM installations using platform: none require customers to:

• Build and maintain their own automation for VM lifecycle and infrastructure integration.
• Design custom storage architectures, often pushing them towards NVMe/TCP or similar setups.

While KubeVirt CSI can technically be used, it is:

• Not provided out of the box in this scenario.
• Tightly coupled to the HCP architecture in current guidance.

To use KubeVirt CSI with underlying bare-metal storage, customers are effectively forced into Hosted Control Planes, inheriting all its drawbacks.