Is there a missing “simple virtualization platform” layer in the Fedora / Red Hat ecosystem?

Hi all,

I’ve been reflecting on how the Fedora / Red Hat ecosystem positions itself around virtualization, especially given the recent changes in the VMware landscape.

Since the Broadcom acquisition, a lot of organizations (large and small) seem to be rethinking their approach. In many cases, the discussion is not about moving to the cloud or Kubernetes — it’s simply about finding a reliable, simpler way to run virtual machines on-prem.


From a technical standpoint, the Fedora ecosystem is already very strong:

  • KVM as a solid hypervisor
  • libvirt and its tooling
  • Cockpit (including cockpit-machines)
  • Ansible for automation

All the core building blocks are there, and they are mature.


What I keep noticing, though, is that solutions like Proxmox VE are gaining traction not because they introduce new technology, but because they offer a fully integrated experience:

  • a unified web interface
  • sensible defaults
  • built-in clustering and high availability
  • and a very short path from installation to a usable platform

This made me wonder if there’s currently a gap between two ends of the spectrum:

  • On one side: Fedora / RHEL + KVM → very flexible, but requires integration effort
  • On the other: OpenShift Virtualization → powerful, but Kubernetes-based and relatively heavy for some use cases

There seems to be space in between for something simpler:

A lightweight, integrated virtualization layer that:

  • does not require Kubernetes
  • is easy to deploy and operate
  • provides a cohesive user experience
  • stays aligned with the Fedora / Red Hat ecosystem

I’m also thinking about smaller environments:

  • small organizations and associations
  • educational setups or labs
  • individuals running a few hosts

These users often don’t have dedicated platform teams or deep Kubernetes expertise. They just need something that works, is easy to understand, and doesn’t take days to assemble.

Right now, the Fedora stack absolutely has the capabilities — but getting from “components” to “usable platform” still takes time and experience.


So I’m curious:

  • Is this gap intentional from a strategic perspective?
  • Is the long-term direction exclusively toward Kubernetes-based virtualization?
  • Are there ongoing efforts (SIGs or upstream projects) to provide a more integrated experience on top of KVM?
  • Or is this space simply out of scope for Fedora / Red Hat?

To be clear, this isn’t a criticism — the technical stack is excellent.

This is more a question about positioning and user experience, especially in the current context where many users are actively looking for simpler virtualization solutions.

Thanks in advance for your insights.

Regards,
GNU Tux

virtualization kvm cloud

I think you’re looking for oVirt: https://www.ovirt.org/ (oVirt - Wikipedia)

It used to be the upstream for a Red Hat product: Red Hat Virtualization - Wikipedia

Latest release is from January 2026.

That looks interesting. Thanks for sharing.

I am wondering why I can not find Fedora listed? :
The following virtual machine guest operating systems are supported:

Operating System Architecture SPICE support [1]
Red Hat Enterprise Linux 3 - 6 32-bit, 64-bit Yes
Red Hat Atomic 7.x 64-bit No
Red Hat Enterprise Linux 7 - 8 64-bit Yes
Red Hat Enterprise Linux 9 64-bit No
Red Hat Enterprise Linux 10 64-bit No
Red Hat Enterprise Linux CoreOS 64-bit No
SUSE Linux Enterprise Server 10+ [2] 32-bit, 64-bit No
Ubuntu 12.04 (Precise Pangolin LTS)+ [3] 32-bit, 64-bit Yes
Windows XP Service Pack 3 and newer 32-bit Yes
Windows 7 32-bit, 64-bit Yes
Windows 8 32-bit, 64-bit No
Windows 10 64-bit Yes
Windows 11 64-bit Yes
Windows Server 2003 Service Pack 2 and newer 32-bit, 64-bit Yes
Windows Server 2008 32-bit, 64-bit Yes
Windows Server 2008 R2 64-bit Yes
Windows Server 2012 R2 64-bit No
Windows Server 2016 64-bit No
Windows Server 2019 64-bit No
Windows Server 2022 64-bit No
Windows Server 2025 64-bit No
FreeBSD 9.2 32-bit, 64-bit No

[1] SPICE drivers (QXL) are not supplied by Red Hat. Distribution’s vendor may provide SPICE drivers.
[2] select Other Linux for the guest type in the user interface
[3] not tested recently (?)

Did you try virt-manager? it is a GUI interface to libvirt and it can connect over the network to manage virtual machine servers, and it has a lot of advanced features, but it is still fairly simple to use. It starts you off with bare metal, and you can install via a .iso file or dvd or you can literally dd a drive and use that image (it don’t recall if it natively does it or of I just created a vm and replaced the file. then recreated the initramfs) It also does stuff like pass-thru. It is not a web-interface, I haven’t used cockpit, as I haven’t needed anything more advanced.

Interesting thoughts. However, I don’t think oVirt is the right choice here. It’s just as complex as Kubernetes, OpenShift and the like, and significantly more complex than Proxmox.

I don’t know what Red Hat thinks about this. In Fedora, it’s certainly not a strategic decision. It’s probably not even a decision at all. It all depends on who takes the initiative and what they’re committed to.

We, the Fedora Server Working Group, leave everything to do with Kubernetes and related matters to the dedicated SIG. This issue goes beyond just Fedora Server. We are focusing on the server itself and its applications in ‘non-Kubernetes’ scenarios. Among other things, we are looking at Fedora Server as a host for VMs. However, we are not aiming for a closed, ‘fully curated’ system, but rather an open, flexible system that can be perfectly adapted to local requirements.

You are invited to get involved in our discussions and our work. Not necessarily in a technical capacity, but also by contributing ideas, testing solutions, and so on. I have, in any case, already given some thought to creating a sort of VM-host spin-off. At the moment, we are creating a spin-off for home servers. It is at least worth discussing whether we want to do something similar for other use cases as well.