Set up KVM and QEMU on Fedora
You installed Fedora Workstation and opened the terminal to spin up a virtual machine. You typed virt-manager and got a permission denied error. Or you ran virt-install and the system complained about missing hardware acceleration. The virtualization stack is present on Fedora, but the pieces need to be connected. This guide gets KVM, QEMU, and libvirt working so you can run VMs with full hardware acceleration and proper permissions.
How the stack works
KVM turns the Linux kernel into a hypervisor. QEMU emulates hardware devices like disks, network cards, and USB controllers. Libvirt is the management layer that provides a unified API to talk to both KVM and QEMU.
Think of KVM as the engine that provides the raw compute power. QEMU is the chassis and dashboard that presents hardware to the guest. Libvirt is the steering wheel and pedals that let you control the vehicle without touching the engine directly. Without KVM, QEMU runs in software emulation mode, which is painfully slow. Without libvirt, you have to manage raw QEMU processes manually and handle permissions, networking, and storage yourself. Fedora bundles these tools, but the service needs to start, your user needs group access, and the kernel modules must load.
Check hardware virtualization
The CPU must support hardware virtualization, and the feature must be enabled in the firmware. Software emulation exists, but it will grind your system to a halt for anything beyond a trivial test.
Run this command to check for the virtualization flags:
# vmx indicates Intel VT-x support
# svm indicates AMD-V support
# head -1 is sufficient; the full output is noisy
grep -E 'vmx|svm' /proc/cpuinfo | head -1
If the output is empty, the CPU does not support virtualization or the feature is disabled in the BIOS/UEFI. Reboot and enter the firmware settings. Look for Intel VT-x or AMD-V and enable it.
If the flag is missing, reboot and enter firmware settings. No amount of software configuration fixes a disabled CPU feature.
Install the package group
Fedora provides a package group that pulls in the entire stack with correct dependencies. Installing packages individually often leaves out critical libraries or tools.
# @virtualization group installs QEMU, libvirt, virt-manager, and dependencies
# -y skips the confirmation prompt
sudo dnf groupinstall -y "@virtualization"
This command installs qemu-kvm, libvirt, virt-manager, virt-install, virt-viewer, and the SPICE client. The group ensures version compatibility across all components.
Run dnf groupinfo virtualization if you want to see exactly what packages are included before installing.
Start the libvirt daemon
Libvirt runs as a system daemon named libvirtd. This daemon manages VMs, networks, and storage pools. It must be running before you can create or control any virtual machine.
# enable ensures libvirtd starts on boot
# --now starts the service immediately
sudo systemctl enable --now libvirtd
Check the service status to confirm it is active and to see recent log lines:
# status shows the current state and the last 10 log lines
# libvirtd logs to the journal, not a separate file
systemctl status libvirtd
Start the daemon before creating VMs. Libvirt creates the default network and storage pool on first run.
Grant user permissions
By default, only the root user can talk to the libvirt daemon. Running every VM command with sudo is unsafe and breaks permission models for disk images and sockets. Add your user to the libvirt group to manage VMs without elevation.
# -aG appends the user to the libvirt group without removing other groups
# $USER expands to your current username
sudo usermod -aG libvirt $USER
Group changes do not apply to running sessions. You must log out and log back in for the change to take effect. If you need immediate access in the current terminal, run newgrp libvirt, but GUI applications like virt-manager still require a full re-login.
Log out and back in. Group changes do not apply to running sessions until you re-authenticate.
Verify kernel modules
KVM requires kernel modules to interface with the CPU virtualization extensions. These modules load automatically when libvirt starts, but it is good practice to verify they are present.
# kvm_intel loads for Intel CPUs
# kvm_amd loads for AMD CPUs
# kvm is the core module both depend on
lsmod | grep kvm
You should see kvm_intel or kvm_amd along with kvm. If the architecture-specific module is missing, check for nested virtualization conflicts or ensure the firmware settings are correct.
If kvm_intel or kvm_amd is missing, check for nested virtualization conflicts or BIOS settings. Software emulation will grind your CPU to a halt.
Choose a disk format
Libvirt supports multiple disk formats. The two most common are raw and qcow2.
Raw images are simple byte-for-byte copies of a disk. They have minimal overhead but cannot shrink and do not support snapshots. Qcow2 images support thin provisioning, compression, encryption, and snapshots. They use only the space they need and grow as data is written.
Use qcow2 for development and testing. Use raw only when a specific guest OS or tool requires it.
Create a disk image manually if you need to pre-allocate storage or use a custom path:
# qcow2 format enables snapshots and thin provisioning
# size=20G sets the virtual size; actual disk usage starts near zero
qemu-img create -f qcow2 /var/lib/libvirt/images/my-vm.qcow2 20G
Use qcow2 for development and testing. Use raw only when a specific guest OS or tool requires it.
Create a VM from the command line
virt-install is the command-line tool for creating VMs. It generates the libvirt XML definition and starts the installation process. This tool is ideal for scripting and automation.
# --name sets the VM identifier for libvirt
# --ram 2048 allocates 2GB of host memory
# --vcpus 2 assigns two virtual CPUs
# --disk creates a qcow2 image with 20GB virtual size in the default pool
# --cdrom points to the installation ISO
# --network network=default attaches to the libvirt NAT network
# --graphics spice enables SPICE display protocol
# --noautoconsole prevents the terminal from hijacking the console
sudo virt-install \
--name fedora-vm \
--ram 2048 \
--vcpus 2 \
--disk size=20,format=qcow2 \
--cdrom /path/to/Fedora-Workstation-Live-x86_64-41.iso \
--network network=default \
--graphics spice \
--noautoconsole
The command returns immediately. Open virt-manager or use virt-viewer to connect to the SPICE display and complete the installation.
Use virt-install for scripted deployments. The GUI is faster for one-off testing.
Manage VMs with virsh
virsh is the command-line interface for libvirt. It provides access to every aspect of VM management, from power control to XML editing.
# --all shows inactive VMs, not just running ones
virsh list --all
# start boots the VM
virsh start fedora-vm
# shutdown sends an ACPI power-off signal to the guest
# this allows the OS to save state and unmount disks
virsh shutdown fedora-vm
# destroy cuts power immediately like pulling the plug
# use this only when the guest is unresponsive
virsh destroy fedora-vm
# dominfo shows CPU, memory, and state details
virsh dominfo fedora-vm
Run virsh list --all to see the state of every domain. Active VMs show running, paused VMs show paused, and shut down VMs show shut off.
Access the console
SPICE provides a graphical console with clipboard sharing and USB redirection. virt-manager and virt-viewer use SPICE by default.
The virsh console command connects to the guest serial port. This works only if the guest OS is configured to output to the serial console. Fedora cloud images enable this by default. Workstation and Server ISOs do not. Attempting to use virsh console on a desktop installation will hang.
Use SPICE or VNC for graphical consoles. Reserve virsh console for headless servers and cloud images.
Networking and SELinux
Libvirt creates a default NAT network named default on the 192.168.122.0/24 subnet. VMs attached to this network get internet access via NAT and can communicate with the host. This setup requires no configuration and works out of the box.
For bridged networking, where VMs appear on the same subnet as the host, you must create a bridge interface and configure libvirt to use it. This requires changes to the host network configuration.
Fedora's SELinux policy allows libvirt to access disk images under /var/lib/libvirt/images/. If you store images in a custom directory, SELinux will block access until you restore the correct context.
# -Rv applies context recursively and prints verbose output
# libvirt_image_t is the required SELinux type for VM disks
sudo restorecon -Rv /path/to/images/
Store images in /var/lib/libvirt/images/ unless you have a storage policy that requires otherwise. SELinux denies access to arbitrary directories by default.
Common errors
Permission denied on socket
error: failed to connect to the hypervisor
error: permission denied: cannot connect to '/var/run/libvirt/libvirt-sock'
This error means your user is not in the libvirt group or the session has not re-authenticated. Run groups to verify membership. Log out and back in if the group is correct.
No accelerator found
error: Failed to create domain from virt-install
error: internal error: process exited while connecting to monitor: qemu-system-x86_64: failed to initialize KVM: Permission denied
This error indicates the kernel module is missing or the user lacks access to /dev/kvm. Check lsmod | grep kvm. Verify the CPU virtualization flag is present. Ensure the libvirt group membership is active.
SELinux denial
error: internal error: cannot open disk image '/home/user/vms/test.qcow2': Permission denied
SELinux blocks access to user home directories by default. Move the image to /var/lib/libvirt/images/ or run restorecon on the custom path. Do not disable SELinux. Fix the context.
Read the error message. Permission denied means group membership or SELinux. No accelerator means BIOS or kernel module. Fix the root cause, don't force the command.
Decision matrix
Use virt-manager when you need a visual interface to configure hardware and access the console. Use virt-install when you are scripting VM creation or working over SSH without a display. Use virsh when you need to manage running VMs, check logs, or edit XML definitions directly. Use the @virtualization group when you want the standard Fedora stack with all dependencies resolved. Use individual packages when you only need a specific tool and want to minimize disk usage. Use qcow2 disk format when you need snapshots or thin provisioning. Use raw disk format when a guest OS requires it or when you need maximum I/O performance without translation overhead.