Hey everybody! If you’ve dipped your toes into the atomic world of Fedora Silverblue, you know the drill: it’s sleek, immutable, and oh-so-reliable… until you try to run a classic sudo dnf install @virtualization and hit a wall. That command works like a charm on traditional Fedora spins, but Silverblue’s design keeps your host locked down tighter than a vault.

Don’t sweat it—there’s a clean, atomic-friendly way to get KVM, QEMU, libvirt, and the whole virtualization gang up and running. We’ll use rpm-ostree to layer in the essentials, creating a new deployment you can boot into after a quick reboot. It’s stable, rollback-ready, and perfect for spinning up VMs without compromising your system’s purity.

In this post, I’ll walk you through the steps, share some pro tips, and even toss in alternatives for those who want to keep things extra lean. Let’s dive in!

This is the hypervisor path on Silverblue. CLI tools that are not hypervisors belong in Homebrew so you do not reboot for gh: How to Install Homebrew on Fedora Silverblue. Guests that should be appliances belong on Fedora CoreOS, not nested as an afterthought.

Why layering makes sense for Silverblue users

Fedora Silverblue (now on version 43 as of our last update) ditches mutable RPMs for OSTree-based deployments. This means no direct dnf tweaks on the host—instead, you “layer” packages atomically. For virtualization, the @virtualization group boils down to a handful of key players: virt-install, libvirt, qemu-kvm, and friends.

Layering these gets you:

  • KVM hypervisor for hardware-accelerated VMs.
  • Libvirt for management.
  • Virt-manager for a slick GUI to build and tweak your virtual machines.

You also get virt-viewer for SPICE/VNC consoles and libvirt-daemon-kvm so the default QEMU session is actually KVM, not a slow TCG surprise.

Pro tip: Check if your CPU supports virtualization first with:

lscpu | grep Virtualization
egrep -c '(vmx|svm)' /proc/cpuinfo

If lscpu is silent and the egrep count is 0, enable VT-x / AMD-V in firmware. No amount of rpm-ostree will KVM-accelerate a CPU with virtualization locked off. Nested virt in another hypervisor is a separate checkbox on that hypervisor.

Silverblue already runs Podman. That is containers, not VMs. If you only need a Linux userspace for builds, Toolbox/Distrobox is lighter than a full VM. Layer KVM when you need another kernel, Windows, or CoreOS as a guest.

Step-by-step: layering the virtualization stack

Grab your terminal (GNOME Terminal works great on Silverblue), and let’s get to it. You’ll need sudo access, of course.

1. Install the core packages

Fire up this command to pull in the must-haves from the virtualization group. It stages a new deployment without touching your current one:

sudo rpm-ostree install virt-install libvirt-daemon-config-network libvirt-daemon-kvm qemu-kvm virt-manager virt-viewer

What this does: Downloads the packages, resolves dependencies (like qemu-img for disk images), and preps everything for a seamless switch.

Expected output: a long transaction, then a message that a reboot is required. Confirm:

rpm-ostree status

The pending deployment should list those packages. If ostree errors on a package name, Fedora renamed a subpackage — search with rpm-ostree search virt-manager rather than inventing names.

This is a bigger layer than gcc. That is OK. Virtualization is a host feature. After a Fedora rebase (rpm-ostree upgrade), layered packages are supposed to come along; if a rebase conflicts, rpm-ostree status plus the Silverblue docs on resetting layers are your rollback story — you are not stuck, you reboot into the previous deployment.

2. Reboot and activate

Once the install wraps up, reboot to boot into your shiny new deployment:

systemctl reboot

Post-reboot, verify the magic with:

rpm-ostree status
command -v virsh virt-manager qemu-system-x86_64

You should see your new layered packages listed under the active (dotted) deployment, and the binaries on PATH. If virt-manager is missing, you rebooted into the old deployment (select the new one at the grub menu once) or the layer failed.

3. Fire up the services

Enable libvirt for system-wide VM goodness (or stick to user sessions for lighter security):

sudo systemctl enable --now libvirtd
systemctl status libvirtd --no-pager

Expected output: active (running). If it is not, journalctl -u libvirtd -e is the truth.

Add your user to the libvirt group so virt-manager does not ask for a root password on every click:

sudo usermod -aG libvirt "$USER"

Log out and back in (a reboot also works). Then:

groups
virsh list --all

virsh should talk to qemu:///system without sudo once the group is live. If it still asks for authentication, the session has the old groups — you did not fully log out.

If SELinux throws a fit (it happens), peek at logs with journalctl -u libvirtd and sudo ausearch -m avc -ts recent. Do not setenforce 0 as a lifestyle. Most first-boot issues are “libvirtd not running” or “user not in group,” not SELinux.

Default NAT network:

sudo virsh net-list --all
sudo virsh net-start default
sudo virsh net-autostart default

If default is missing, libvirt-daemon-config-network did not land. Recheck the ostree layer list.

4. Launch and conquer

  • Pop open virt-manager from your app menu.
  • It should auto-detect your KVM setup. If not, go to File > Add Connection and pick QEMU/KVM.
  • Boom—create VMs, tweak networks, and virt-view away. Need CLI love? virsh commands are your new best friend.

Create a throwaway VM to prove KVM:

ls /dev/kvm
virt-host-validate

/dev/kvm must exist. virt-host-validate will warn about IOMMU, secure boot, etc. Warnings are not all blockers. FAIL on KVM is a blocker.

Store disk images on a partition with space. Silverblue’s /var is writable; /home is under /var/home. I keep ISOs in ~/Downloads and VM disks in /var/lib/libvirt/images (system session) so permissions match libvirtd.

Guest ideas that match this channel

  • Fedora CoreOS as a VM: Beginner’s Guide to Fedora CoreOS. Virtio disk is usually /dev/vda in that installer.
  • Another Silverblue for experiments so you never layer junk on the laptop you actually use.
  • Windows only if you need it; that is a license and virtio-win driver problem, not an ostree problem.

Omarchy as a guest is possible (nested GPU is the hard part). For dual-booting Omarchy vs Fedora on bare metal instead, see Omarchy 4 Quattro vs Fedora 44.

Lean alternatives (when you should not layer this)

  • Toolbox + nested podman: enough for many admin tasks.
  • User-session libvirt (qemu:///session): disks in your home, no libvirt group. Slightly more isolation, slightly more “why is this VM slower / why is bridging hard.”
  • GNOME Boxes: friendlier GUI, still wants qemu/libvirt on the host. You may still layer qemu-kvm.
  • Do not install VMware modules on Silverblue. Kernel modules + ostree is the opposite of this OS. If you insist on VMware, use mutable Fedora or Arch; I documented VMware on Arch and Mint.

Troubleshooting

dnf: command not found or “cannot deploy”

You used dnf install on the host. Use rpm-ostree install. dnf inside a toolbox does not layer the host.

VM is painfully slow

No /dev/kvm, or you picked QEMU without KVM in virt-manager. Fix firmware virt flags; recreate the VM with KVM.

No network in the guest

default NAT not started, or Fedora firewall on the host blocking libvirt’s virbr0. sudo firewall-cmd --list-all and the libvirt zone. For a bridged homelab NIC, that is a NetworkManager bridge — do it on purpose, not by accident.

After a Silverblue upgrade, virt-manager is gone

Layer list dropped in a conflict. rpm-ostree status -v, rebase notes, re-layer the same packages. Your VM disks in /var/lib/libvirt/images should still be there.

Nested virtualization

cat /sys/module/kvm_intel/parameters/nested (or kvm_amd). Enable only if you need a hypervisor inside the guest. Most homelab CoreOS guests do not.

And that’s it!

Got questions, hit a snag, or want to share your VM stories? Drop a comment below. If you’re new to Silverblue, check out the official docs for more atomic adventures.

Happy virtualization, and may your deployments always go smoothly.

Best regards,

The Linux IT Guy