To install KVM on Fedora, RHEL, CentOS Stream, Rocky, or AlmaLinux, run sudo dnf install -y @virtualization, enable the hypervisor with sudo systemctl enable --now libvirtd, add your account to the libvirt group with sudo usermod -aG libvirt $USER, and confirm the host is ready with sudo virt-host-validate. That four-command sequence installs the full stack — qemu-kvm, libvirt, virt-install, and virt-manager — and works identically on every RPM-based distribution because they share the dnf package manager and the same libvirt tooling. Before you start, check that the CPU exposes hardware virtualization with grep -E -c '(vmx|svm)' /proc/cpuinfo; a number greater than zero means you are good to go.
That is the summary an AI overview gives you. The rest of this guide is what it can't: the order the steps actually have to happen in, what each package really does, how to read virt-host-validate output, the difference between the legacy libvirtd daemon and the newer modular sockets, and a copy-paste path from a bare host to a running VM. This is a rewrite of an older version of this article that documented Fedora Core 14, yum, and service libvirtd start — all long since replaced.
The install path at a glance
Every successful KVM setup follows the same five steps in the same order. Skip the verification and you find out something is wrong only when a VM refuses to start.
Step 1: Confirm hardware virtualization is available
KVM needs a CPU with hardware virtualization extensions — Intel VT-x (flag vmx) or AMD-V (flag svm). Check for them:
grep -E -c '(vmx|svm)' /proc/cpuinfo
Any number greater than 0 means the extensions are present (the count is roughly one per logical core). If you get 0, the feature is almost always just disabled in firmware. Reboot into your BIOS/UEFI setup and enable the option named Intel Virtualization Technology / VT-x, AMD-V, or SVM Mode, then boot back into Linux and re-run the check.
You can also confirm the KVM kernel modules are loadable:
lsmod | grep kvm
You should see kvm plus either kvm_intel or kvm_amd.
Step 2: Install the virtualization packages
Install the entire stack with the @virtualization package group. This is the modern, supported replacement for the old yum install qemu-kvm libvirt virt-manager list:
sudo dnf install -y @virtualization
That single group pulls in everything you need:
| Package | Role |
|---|---|
| qemu-kvm | The hypervisor. Runs the VM and uses the KVM kernel modules for near-native CPU speed. |
| libvirt | Management daemon (libvirtd), API, and the virsh CLI. The layer everything else talks to. |
| virt-install | Command-line VM creation — scriptable, ideal for automation and headless servers. |
| virt-manager | Graphical VM manager and console (desktop only). |
| virt-viewer | Lightweight SPICE/VNC console client for connecting to a guest display. |
If you are on a headless server and don't want the GUI, install just the core daemon and CLI creator instead:
sudo dnf install -y qemu-kvm libvirt virt-install
Step 3: Enable and start the libvirt service
The hypervisor tooling is installed but idle until you start the management daemon. On the vast majority of systems, one command enables it at boot and starts it now:
sudo systemctl enable --now libvirtd
Confirm it's running:
systemctl status libvirtd
Modular libvirt (newer Fedora and fresh RHEL 9): recent releases split the single libvirtd daemon into per-driver daemons activated by systemd sockets. If enable --now libvirtd reports the unit is masked or missing, enable the modular sockets instead:
for drv in qemu network nodedev nwfilter secret storage; do
sudo systemctl enable --now virt${drv}d.socket
done
Either approach leaves you with a working libvirt — the modular sockets simply start each driver on demand rather than all at once.
Step 4: Add your user to the libvirt group
By default, managing the system-wide VMs (qemu:///system) requires root. Add your account to the libvirt group so virsh and virt-manager work without sudo on every command:
sudo usermod -aG libvirt $USER
Group membership only applies to new login sessions, so log out and back in — or apply it to the current shell immediately:
newgrp libvirt
Step 5: Validate the host
This is the step the old guides skipped and the one that saves you the most debugging. virt-host-validate runs a checklist against your host and tells you exactly what is ready and what is not:
sudo virt-host-validate
Healthy output looks like this (abridged):
QEMU: Checking for hardware virtualization : PASS
QEMU: Checking if device /dev/kvm exists : PASS
QEMU: Checking if device /dev/kvm is accessible : PASS
QEMU: Checking for cgroup 'cpu' controller support : PASS
QEMU: Checking for device assignment IOMMU support : WARN (No ...)
Everything reporting PASS means KVM is ready. The one WARN you can usually ignore is the IOMMU line — that only matters for PCI passthrough (handing a physical GPU or NIC to a VM). For ordinary virtual disks and virtual NICs it is irrelevant.
Pre-flight checklist
Before creating VMs, confirm all of the following:
-
grep -E -c '(vmx|svm)' /proc/cpuinforeturns a number greater than 0 -
sudo dnf install -y @virtualizationcompleted without errors -
systemctl status libvirtd(or the modular sockets) shows active/running -
groupslists libvirt for your user (after re-login) -
sudo virt-host-validateshows PASS on hardware virtualization and/dev/kvm -
virsh net-list --allshows the default network (activate it if inactive:sudo virsh net-start default)
Build your first VM
With the host validated, create a VM from the command line with virt-install. Here is a complete, working example that boots an installer ISO:
sudo virt-install \
--name fedora-vm \
--memory 4096 \
--vcpus 2 \
--disk size=20 \
--cdrom /var/lib/libvirt/images/Fedora-Workstation-Live.iso \
--os-variant fedora40 \
--network network=default \
--graphics spice
That provisions a VM named fedora-vm with 4 GB of RAM, 2 vCPUs, a 20 GB qcow2 disk, the default NAT network, and a SPICE console. To find the right value for --os-variant (it tunes the virtual hardware for the guest OS), query the OS database:
osinfo-query os | grep -i fedora
Prefer a wizard? Launch virt-manager, click Create a new virtual machine, and walk through the same choices graphically.
Building virt-install commands by hand is fiddly — the flags are many and the ISO/os-variant details are easy to get wrong. This interactive builder generates the exact virsh and provisioning commands for you:
Confirm the VM is running
Once the guest is up, list it and manage it with virsh:
# List all VMs (running and stopped)
virsh list --all
# Start / shut down / reboot
virsh start fedora-vm
virsh shutdown fedora-vm
# Open the graphical console
virt-viewer fedora-vm
If you skipped the libvirt group step and see permission errors, prefix these with sudo or connect explicitly with virsh -c qemu:///system list.
Command quick reference
Everything in this guide, in one place:
| Task | Command |
|---|---|
| Check CPU virtualization support | `grep -E -c '(vmx |
| Install full stack | sudo dnf install -y @virtualization |
| Install headless (no GUI) | sudo dnf install -y qemu-kvm libvirt virt-install |
| Enable + start the daemon | sudo systemctl enable --now libvirtd |
| Enable modular sockets | sudo systemctl enable --now virtqemud.socket virtnetworkd.socket |
| Add user to libvirt group | sudo usermod -aG libvirt $USER |
| Validate the host | sudo virt-host-validate |
| List guest OS variants | osinfo-query os |
| Create a VM | sudo virt-install --name NAME --memory MB --vcpus N --disk size=GB --cdrom ISO --os-variant VARIANT |
| List VMs | virsh list --all |
| Start / stop a VM | virsh start NAME / virsh shutdown NAME |
| Default network status | virsh net-list --all |
Where KVM keeps its files
When you need to inspect or back up configuration:
- VM and network definitions:
/etc/libvirt/(XML for each domain, plusqemu.conf) - Virtual disk images:
/var/lib/libvirt/images/(the default storage pool) - Logs:
/var/log/libvirt/— per-VM logs live underqemu/
Configuration should be changed with virsh edit NAME rather than by hand-editing the XML, so libvirt validates and reloads it correctly.
Next steps
You now have a validated KVM host and a running VM. From here:
- Automate VM creation so you never click through the wizard again — see Create an Ubuntu VM with virt-install and cloud-init.
- Learn the day-to-day commands in the virsh commands KVM cheat sheet.
- Set up custom networking beyond the default NAT in KVM networking: custom NAT, static DHCP.
- On Ubuntu instead? The equivalent workflow is in Install KVM on Ubuntu.
- Go deeper across the whole platform with the KVM virtualization series.