Red Hat Virtualization vs OpenStack: when each one fits
If your Red Hat Virtualization estate is approaching the end of its Extended Life Phase on August 31, 2026, and you now need tenant isolation, self-service provisioning or chargeback, the choice is no longer just a like-for-like hypervisor swap. RHV-style clusters remain the simpler answer when you have a small number of internal owners, a stable catalog of VM templates and administrators who are comfortable working in one management plane. In that case a virtualization-focused platform such as oVirt or Proxmox VE keeps the operating model close to what your team already runs. OpenStack becomes the better destination when several business units or external customers need isolated projects, quotas and their own networks, and when they expect to request resources without opening a ticket.
Four factors should drive the decision. The first is tenant count and how strongly tenants must be separated, since OpenStack uses Keystone projects, roles and federated identity mappings to enforce that boundary. The second is self-service expectations: if users expect to create networks, volumes and instances through an API or dashboard, you are buying a cloud control plane, not a cluster manager. The third is storage strategy. OpenStack normally depends on Ceph for Glance, Cinder and Nova disks, so you need a plan for Ceph hardware, OSD layout and network design before any workload moves. The fourth is team capacity. Confirm with your own staff how many people can operate Keystone, Nova, Neutron, Ceph and upgrades on a six-month release cadence, and whether a partner or retainer will cover the gap.
Before committing, run a short pilot with three checks: a tenant onboarding workflow end to end, a Ceph failure drill on your planned hardware, and a timed upgrade rehearsal against the current OpenStack release line in the OpenStack releases site. If the pilot shows that your tenants need only isolated VMs and little else, a smaller platform is probably the right answer. If it shows that tenant self-service is the core requirement, OpenStack is worth the operating investment. Ask any implementation partner to put these checks into a written scope with named deliverables before work starts.
Which estates should choose OpenStack over RHV
This table compares common RHV estate scenarios against an OpenStack cloud built on Ceph, Neutron and Keystone. Read each row as a fit test: the better fit column names the platform that matches the scenario, and the reason column explains what drives that answer. Where the answer depends on facts only you can confirm, the row says what to check first.
| Scenario | Better fit | Why and what to confirm |
|---|---|---|
| One business unit with a stable VM count | RHV successor on a single cluster (oVirt, KubeVirt or Proxmox VE) | A single team with predictable capacity rarely needs project quotas or a tenant API. Confirm that no other internal group is expected to self-provision within the next planning cycle. |
| Many internal tenants requesting projects on demand | OpenStack | Keystone projects, roles and quotas map directly to tenants, and Keystone federation can map users from a corporate identity provider to groups and projects. Confirm that your identity provider can supply the group claims the mapping rules need. |
| API-driven provisioning from pipelines and portals | OpenStack | Nova, Neutron, Cinder and Glance expose APIs designed for automation by tooling such as Terraform or internal portals. Confirm which API clients your teams already use, since OpenStack client libraries and CLIs will need to be supported. |
| Ceph is already the storage strategy | OpenStack | Ceph block devices can back Glance images, Cinder volumes and Nova guest disks, so VMs boot from Ceph without local hypervisor storage. Confirm that Ceph has enough dedicated hardware, since the Ceph hardware guidance calls for dedicated drives per OSD and bonded network links. |
| Ceph is not yet in place and storage is a SAN | Proxmox VE or an oVirt successor | Adopting Ceph adds a second distributed system to operate beside the hypervisor. Confirm whether the storage team will own Ceph operations before choosing OpenStack for this reason alone. |
| Team with no cloud operations experience | RHV successor or Proxmox VE | OpenStack has many services to run, upgrade and troubleshoot, including identity, networking, block storage and the message bus. Confirm whether you can staff this skill set or fund an implementation partner for the first years of operation. |
| Network isolation per tenant with overlay networks | OpenStack | Neutron with OVN provides tenant networks, routers and security groups as self-service objects. Confirm that your physical network team can support the required VLAN or overlay design and MTU settings. |
| Long-term upgrade planning | OpenStack, with a SLURP release path | OpenStack upgrades are supported between SLURP releases as well as adjacent releases, which shapes the upgrade calendar. Confirm which release your team will standardize on and when it leaves maintenance. |
How RHV's data center model maps onto an OpenStack cloud
RHV runs its estate through one management plane. The Engine holds the inventory of data centers, clusters, hosts and storage domains, and it is the place where administrators define logical networks, quotas and VM placement. Hosts join a cluster, a cluster belongs to a data center, and storage domains attach to that data center. Compute, storage and network decisions are made in one console and one database, which is why small and mid-sized estates find RHV straightforward to run. OpenStack does not offer that single point of control. Nova schedules instances onto compute hosts, Cinder provides block volumes, Neutron manages virtual networks, and Keystone issues identities, projects and roles. Each service has its own API, its own database and its own configuration, and a cloud operator decides how they are assembled. Confirm which OpenStack release line and which deployment tool (for example, Kolla-Ansible or OpenStack-Ansible, both covered in the 2026.1 deployment guides) your team will standardize on before mapping any RHV object.
That separation is the reason to consider OpenStack at all. Projects act as tenant boundaries, so one team's instances, volumes and networks can be isolated from another's, and users can request resources through the API or dashboard without an administrator creating each object. Keystone federation supports SAML 2.0 and OpenID Connect, and mapping rules translate identities from your corporate identity provider into OpenStack groups, roles and projects. In an RHV estate, these tenancy rules usually live in administrator-defined permissions on clusters and pools. Map each existing RHV permission to a project, a role and a quota, and document who may create networks, floating IPs and volumes. Storage is the other split: Ceph can back Glance images, Cinder volumes and Nova guest disks, so VMs can boot from Ceph rather than local hypervisor storage. Ceph is a separate cluster with its own monitors, OSDs and placement decisions, and it needs its own capacity planning and operations skills.
The moving parts are where migrations go wrong. A single RHV cluster failure has one set of logs to read, while an OpenStack instance that will not boot may involve Nova scheduling, a Glance image, a Cinder backend, a Neutron port and a Ceph pool. Before any VM moves, have the team build a small reference environment, trace one instance through each service, and rehearse the failure paths they will be paged for. Decide who owns each service, how upgrades between releases will be sequenced, and which OpenStack release and stable-branch window the platform will follow, since stable branches are maintained for approximately 18 months. Confirm with your OpenStack distribution or integrator which operational tooling, monitoring and backup approach they support for the chosen deployment model.
Which OpenStack services take over which RHV functions
RHV combines a central engine, KVM hosts, storage domains and a single administrative portal. An OpenStack cloud splits those jobs across separate services, so each RHV function maps to a named component. Confirm every service choice and version against the OpenStack release you plan to deploy, since the set of supported options changes between releases.
Compute with Nova
Nova schedules and runs instances on KVM hosts and replaces the RHV engine's role of placing VMs on hypervisors. Your RHV clusters and host groups become Nova availability zones, aggregates and host placement rules. Check how your current affinity rules, host pinning and live migration needs translate, because Nova's scheduler works from filters and weights rather than from RHV cluster policies. Confirm the hypervisor driver and live migration behavior for your release.
Images with Glance
Glance stores the templates and ISO files that RHV keeps in its ISO and export domains and template library. Each image gets metadata such as OS type and hardware properties that Nova uses at boot. Inventory your RHV templates before migration, decide which ones become Glance images and which need rebuilding, and confirm the storage backend Glance uses for your target release.
Block storage with Cinder on Ceph RBD
Cinder provides persistent block volumes, the job RHV storage domains do for VM disks. Ceph RBD can back Cinder volumes, Glance images and Nova guest disks, so VMs can boot from Ceph without local hypervisor storage. Plan the Ceph cluster as a separate design exercise, including OSD layout, WAL and DB placement and network bonding, and benchmark it before you commit to hardware.
Networking with Neutron and OVN
Neutron replaces the logical networks, vNICs and network profiles that RHV manages through its engine. OVN is the usual mechanism driver to evaluate for tenant networks and routing. Map each RHV logical network to a provider or tenant network, and document VLANs, MTU and any external routing. Confirm the ML2 driver and OVN features you need against your target release before you design tenant isolation.
Identity with Keystone
Keystone issues tokens and organizes access through projects, roles and groups, which is the multi-tenant model RHV does not provide natively. Federation over SAML 2.0 or OpenID Connect lets you connect an existing identity provider, and mapping rules link federated users to groups, roles and projects. Decide early which directory is authoritative and test mapping rules with real group membership before cutover.
Self-service with the Horizon dashboard
Horizon is the web dashboard that gives tenants self-service over instances, volumes, images and networks, which replaces the RHV Administration Portal for most user tasks. Administrators still need the command line and APIs for host operations and troubleshooting. Test how Horizon presents your tenant model to users, and confirm which dashboard features your deployment tooling enables.
How Red Hat Virtualization and OpenStack compare on capability
This table compares RHV data centers and clusters with an OpenStack cloud built on Ceph, Keystone and Neutron, row by row across scope, tenancy, storage, networking, identity, licensing and support. Read each open-source cell with its condition, because OpenStack gains its advantages only when the team can operate the extra services, and several capabilities must be verified in your own deployment. The main takeaway is that OpenStack fits multi-tenant self-service needs, while a cluster-scoped RHV replacement may be simpler for a single-tenant estate.
| Capability | Red Hat Virtualization | OpenStack (Apache-2.0) |
|---|---|---|
| Scope | Virtualization cluster managed by the RHV engine, with data centers, clusters and hosts | Cloud control plane with compute, block, image, network and identity services, typically spanning many hosts and sites |
| Multi-tenancy | Administrative separation is mainly by cluster and permissions, which suits fewer internal owners | Projects, quotas and roles are native to Keystone, which suits many tenants; confirm the isolation model you need |
| Self-service provisioning | Users typically request VMs through administrators or a portal built on the engine API | Users can request compute, volumes and networks through Horizon or APIs; policy design is your responsibility |
| Identity integration | Directory integration is configured through the engine; confirm the protocols your identity provider supports | Keystone federation supports SAML 2.0 and OpenID Connect, with mapping rules to groups, roles and projects; confirm your IdP setup |
| Storage | Storage domains on NFS, iSCSI, FC or Gluster, depending on the RHV configuration in use | Ceph can back Glance images, Cinder volumes and Nova disks, so VMs can boot from Ceph; this needs a properly sized Ceph cluster |
| Networking | Logical networks managed by the RHV engine across hosts in a cluster | Neutron manages software-defined networks; OVN is a common mechanism driver, but confirm the driver and features your release supports |
| Licensing | Red Hat subscriptions cover RHV and support; the product is not open source | Official OpenStack projects are Apache License 2.0, so software cost is zero, while support, hardware and staff are recurring costs |
| Vendor support model | Commercial support from Red Hat for the product while it remains in a supported phase | Community support, distributor or vendor support contracts, or an implementation partner; ask for a written support scope |
| Operating effort | Single engine and a cluster-level skill set for most virtualization teams | Requires skills across identity, compute, storage, networking and upgrades; OpenStack releases follow a six-month cadence with SLURP upgrade paths |
Where your data sits and who controls the cloud
Moving from Red Hat Virtualization to OpenStack changes more than the hypervisor. The cloud control plane, identity, storage and the people who operate them all move into a platform that your organization must run, or contract for, in its own environment. The cards below cover the decisions that determine where data sits, who can reach it and what evidence an assessor will ask for.
Data location in your own facilities
An OpenStack cloud on Ceph keeps VM disks, images, volumes and backups on storage you deploy in your own data centers or cloud accounts. Nothing in the design requires a vendor-hosted control plane, so the key question is physical and logical placement: which sites hold Ceph monitors, OSDs and the Object Gateway, and whether replicas or backups cross a jurisdictional boundary. Confirm the placement of every backup target, since copies often leave the primary site without anyone deciding that they should.
Self-run, partner-run or vendor-supported
Hosting models differ in who holds the operational keys. Self-run means your team installs and patches the cloud, using a deployment tool such as Kolla-Ansible or OpenStack-Ansible. Partner-run means an implementation partner operates it under a written scope, and vendor-supported means a commercial distribution carries the support contract. Ask each candidate who holds root and administrative credentials, who is on call, and who can approve a change to the control plane.
Identity federation and access reviews
Keystone federation supports SAML 2.0 and OpenID Connect, and mapping rules translate federated users into OpenStack groups, roles and projects. Access reviews get simpler when those mapping rules are the single source of project membership, but they get harder when local Keystone users or administrator accounts exist outside the directory. Export the mapping rules, the role assignments per project and the list of local accounts, then confirm that each review cycle can evidence all three.
Administrative access to the Ceph layer
Ceph administration is a separate trust domain from OpenStack projects. A tenant with a valid OpenStack role does not gain Ceph access, but anyone who runs cephadm or reaches the Ceph Dashboard can read or alter every pool. The Dashboard supports SAML 2.0 single sign-on, and OAuth2 when cephadm runs the Management Gateway and OAuth2 Proxy services. Decide which accounts can reach the Dashboard and record how those sessions are logged and reviewed.
Evidence for compliance assessments
Regulated organizations must show an assessor that controls work as described, usually across access control, change management, logging, backup and encryption in transit. Ceph's msgr2 secure mode encrypts post-authentication traffic, which supports your transport control narrative, but the assessor will still ask for configuration exports, access logs and change records. DeployOpen prepares systems, controls and evidence for these assessments. Independent auditors issue any audit report or attestation, so confirm early which framework and which auditor the organization will use.
What OpenStack costs to operate compared with RHV subscriptions
The cost comparison comes down to who pays for what, and when. An RHV estate carries a recurring subscription and support fee paid to Red Hat, plus the hardware, the engine host and the staff who run it. An OpenStack cloud removes the per-host subscription line but replaces it with recurring labor and a larger set of components to keep current. The OpenStack side has no vendor invoice, so the cost sits in hardware, people and tooling. Ask your team to price each line separately so the two sides can be compared on the same basis, and ask any integrator for a written scope and quote before comparing totals.
One-time costs on the OpenStack side include architecture and design, the initial deployment with Kolla-Ansible or OpenStack-Ansible, the migration of VMs and their storage, and the purchase of controller, compute and Ceph storage hardware. Ceph hardware is often the largest single item. The Ceph hardware recommendations call for a dedicated drive per OSD, WAL and DB on shared SSDs for HDD-based OSDs, enterprise-class SSDs for metadata, bonded network links across two switches, and memory sized for peak use. Each of these choices raises or lowers the bill, and the Ceph documentation advises benchmarking before buying because no two clusters are alike.
Recurring costs are the most important part of the comparison. Staff time covers operating the control plane, Keystone federation and mapping rules, Ceph health, patching and capacity planning. Upgrades carry a cost of their own: OpenStack releases follow a six-month cycle, and the Ceph releases page lists Squid and Tentacle as the maintained lines with set end-of-life dates, so your team must plan a rolling upgrade path against those dates. Monitoring, backup and any support contract for OpenStack or Ceph also recur. Ask a quote to show annual labor estimates, the support model you would rely on in production, and which upgrade windows it assumes.
How a move from RHV to an OpenStack cloud runs
The sequence turns a set of RHV data centers and clusters into an OpenStack cloud with tenants, Ceph-backed storage and federated sign-in, then moves workloads over in tested stages before the RHV estate is retired.
Inventory VMs, networks and storage domains
The platform team lists every RHV data center, cluster, host, virtual machine, network and storage domain, along with the owners, dependencies and compliance scope of each workload. Application teams confirm which VMs need multi-tenant isolation, which need self-service provisioning and which should stay on a plain hypervisor. The step is done when the inventory is reviewed by the application owners and every VM has a target project, network and storage class on paper. Confirm the export and import paths for each disk format with your own environment before you commit to a method.
Design tenants, projects, roles and networks
Architects map the existing RHV organization onto OpenStack domains, projects, user groups and roles, and define the network segments each tenant needs. Networking is designed around Neutron, including how provider networks reach existing VLANs and how overlay networks are handled with OVN. The output is a written design that the security and network teams sign off, covering who can create resources, which quotas apply and how tenants are separated. Ask the vendor or community documentation to confirm the Neutron and OVN features your chosen release supports before finalizing the design.
Build the Ceph cluster and deploy OpenStack
The team builds a Ceph cluster sized for the workload, with a dedicated drive per OSD, shared SSDs for WAL and DB on HDD-based OSDs and bonded network links across two switches, as the Ceph hardware recommendations advise. Ceph is deployed with cephadm, or with Rook if the control plane runs on Kubernetes, and then connected to Glance, Cinder and Nova so guest disks can live on Ceph. OpenStack is deployed with Kolla-Ansible or OpenStack-Ansible. Choose a release still in its maintained phase at deployment time, and plan upgrades between SLURP releases, since upgrades are supported between them. The step is done when a test VM boots from Ceph and a volume can be created, attached and backed up.
Connect Keystone federation to the identity provider
Identity engineers configure Keystone federation with the corporate identity provider using SAML 2.0 or OpenID Connect, and write mapping rules that place federated users into the correct groups, roles and projects. Administrative access and break-glass accounts are defined separately and tested. The step is complete when users from each group sign in, land in the right project with the right role and are denied access to other tenants. Confirm with the identity provider's vendor how group claims are issued, because the mapping rules depend on them.
Migrate workloads cluster by cluster with testing
Workloads move in waves, one RHV cluster at a time, starting with low-risk test systems. For each wave, the team exports or imports disks into the new cloud, rebuilds network attachments, updates guest drivers and agents, and runs application-level tests with the owners. Rollback criteria and a cutover window are agreed before each wave. The wave closes when the application owners sign off and backups for the migrated VMs have restored successfully in the new cloud. Run each wave's test plan with the application teams, not only the platform team.
Retire RHV after the exit plan is settled
Once every workload has moved and been accepted, the team decommissions the RHV engine, hosts and storage domains in a controlled order and keeps the final backups and configuration exports in a retained archive. Retirement is scheduled against the Extended Life Phase planning that the organization has already settled, so that no production system depends on RHV at the time it is shut down. The step is complete when the archive is verified, the decommission is documented and the operations runbooks for the OpenStack cloud are handed over. Confirm the Extended Life Phase dates directly with Red Hat before setting the final shutdown date.
Questions buyers ask before choosing OpenStack over RHV
How much effort does running an OpenStack cloud take compared with RHV?
Running OpenStack takes considerably more ongoing effort than running an RHV engine and its hosts, because you operate a set of services rather than one management engine. The work spans the identity service, compute, networking, block and image storage, the control plane, and the Ceph cluster underneath it. Effort rises with the number of services you enable, the number of tenants, and how often you upgrade. OpenStack has a six-month release cycle, and the 2026.1 Gazpacho release is a SLURP release, so upgrades between SLURP releases are supported. Confirm with your own team how many upgrades per year you can absorb, and whether your deployment tool and monitoring cover every service you plan to run.
How long does a migration from RHV to OpenStack take, and what drives that time?
The timeline depends on far more than the number of VMs. The main drivers are the number of distinct workloads that need re-platforming, the size of the disks being moved, how much of the network design must be rebuilt in Neutron, whether you need to rebuild the identity model with projects and roles, and how much Ceph capacity and hardware you must add before the first VM moves. Teams also lose time on application owners who must sign off on downtime and on validation testing. Because no fixed duration applies to every estate, ask any provider for a written, phased plan with milestones, and ask which parts depend on your own change windows and approvals.
Can an internal team run OpenStack without outside help?
Some teams can, but only if they already run Linux, Ansible, networking and distributed storage well, and they have on-call coverage for the control plane. OpenStack's 2026.1 deployment guides cover Kolla-Ansible, which deploys in Docker containers with Ansible, and OpenStack-Ansible, which deploys in LXC containers or on bare metal. Either approach gives you a repeatable deployment, but you still own troubleshooting, backups, capacity planning and security patching. Many organizations choose a fixed-scope build with documented runbooks, then move to a retainer for upgrades and testing. Ask whether the handover includes knowledge transfer, runbooks and a tested recovery procedure.
What skills and staffing does an OpenStack operations team need?
The team needs skills in several areas at once: Linux administration, Ansible, OpenStack service internals, Neutron networking with OVN, Keystone identity and federation, and Ceph administration. In practice that means people who can read logs across services, plan capacity and reason about failure domains. Keystone federation covers SAML 2.0 and OpenID Connect, and mapping rules connect federated users to groups, roles and projects, so identity engineers are also needed. Staffing levels depend on how many environments you run, your availability targets and whether you have a separate platform team. Confirm during planning which roles you can fill internally and which you will buy as support.
How does Ceph fit into an OpenStack design?
Ceph usually provides the shared storage that makes OpenStack useful at scale. Ceph block devices can back Glance images, Cinder volumes and backups, and Nova guest disks, so VMs can boot from Ceph without local hypervisor storage. Ceph is licensed under LGPL-2.1 or LGPL-3.0, and the project itself offers no paid edition. Its hardware guidance recommends a dedicated drive per OSD, enterprise-class SSDs for metadata, bonded network links across two switches, and memory sized for peak use. Ceph Squid (19.2.x) has an estimated end of life of October 31, 2026, while Tentacle (20.2.x) is the newer active release. Benchmark your hardware before buying, and confirm which Ceph release your storage vendor or support partner will certify.
Is OpenStack the right answer for a small RHV estate?
For many small estates, OpenStack is more platform than the workload needs. OpenStack pays off when you need multi-tenancy, self-service provisioning, API-driven resource management across many teams, or a private cloud that several business units share. If your RHV estate is a handful of hosts running a stable set of VMs for one team, an RHV-to-oVirt or RHV-to-Proxmox VE path usually involves less operational overhead. Ask yourself whether the self-service and tenancy features are required this year, or only planned. Compare the staffing needed for OpenStack against the effort of the simpler destinations before you commit.
What should we confirm before we commit to an OpenStack plan?
Confirm the requirements that change the design most: the number of tenants and projects, the self-service actions users need, the identity source and federation model, the storage capacity and performance you need from Ceph, and the networking features that Neutron and OVN must provide. Confirm the OpenStack release you will deploy and when its maintenance phase ends, since stable branches are maintained for approximately 18 months. Also confirm your upgrade cadence, backup and disaster recovery targets, and who signs off on changes. Ask any provider for a written scope, deliverables and timeline before work starts.
How DeployOpen helps evaluate, implement and migrate
DeployOpen plans, implements and hands over self-hosted open-source platforms inside your own infrastructure, so an OpenStack evaluation starts from your RHV estate, your tenancy model and your team's operating capacity. Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins.
How we scope
- Inventory RHV data centers, clusters, storage domains and VM dependencies to define what the OpenStack cloud must replace.
- Define tenant, project and self-service requirements, and document which workloads stay on virtualization and which move to the cloud.
- Agree the written scope, deliverables and timeline with you before any build work starts, with no prices in the scope itself.
How we build
- Plan the control plane, Ceph storage layout and Neutron networking with OVN against your hardware and failure domains.
- Deploy the chosen OpenStack release with a documented deployment method, then test identity federation, quotas and tenant isolation.
- Run migration rehearsals on sample VMs and record the results, including network mappings, guest driver changes and rollback steps.
How we hand over
- Deliver architecture records, runbooks for daily operations, upgrade procedures and backup and restore tests.
- Train your platform, storage and network staff to operate the cloud, including tenant onboarding and capacity checks.
- Provide a cutover plan that your team can execute, with clear checkpoints for moving each RHV cluster.
How we support
- Offer ongoing support, upgrades and continuous security testing as a retainer after handover.
- Plan OpenStack upgrades around the release cycle and the maintained status of your chosen release, with the work agreed in writing.
- Prepare systems, controls and evidence for compliance assessments, while independent auditors issue any audit reports or certifications.
