Story / scenario opener
You just finished a clean Fedora install and want to spin up a test VM. You type virt-install, but the command fails with a permission denied error. Or maybe systemctl status libvirtd shows the service is inactive. The hypervisor stack is not running because Fedora ships with a minimal base. You need to assemble the pieces yourself.
What is actually happening
KVM is a kernel module that turns Linux into a bare-metal hypervisor. QEMU provides the hardware emulation layer. Libvirt is the management daemon that ties them together and exposes a stable API. Think of KVM as the engine, QEMU as the chassis, and libvirt as the dashboard and steering wheel. Without libvirt, you are manually wiring every virtual CPU, disk, and network interface. With it, you get a unified control plane. Fedora does not install these by default to keep the base image lean. You must opt into the virtualization stack.
The libvirtd daemon runs as root and listens on a Unix socket. It handles VM lifecycle, network bridges, and storage pools. Your regular user account cannot talk to that socket by default. Adding your user to the libvirt group grants access to the socket without giving you full root privileges. This is the standard Linux pattern for service access control. The daemon reads its configuration from /etc/libvirt/. Files in /usr/lib/libvirt/ ship with the package and get overwritten on updates. Always edit the /etc/ copies.
The setup procedure
Install the core virtualization packages in a single transaction. The qemu-kvm package pulls in the kernel module and QEMU binaries. The libvirt packages provide the daemon and configuration files. The virt-install package gives you a command-line interface for provisioning.
sudo dnf install -y qemu-kvm libvirt libvirt-daemon-config-network libvirt-daemon-kvm virt-install
# --refresh forces dnf to check for updated metadata before resolving dependencies
# libvirt-daemon-config-network sets up the default NAT bridge on first boot
# libvirt-daemon-kvm enables hardware acceleration support in the daemon
Enable the libvirt daemon and start it immediately. Systemd will manage the service across reboots.
sudo systemctl enable --now libvirtd
# enable creates the symlink in /etc/systemd/system for boot persistence
# --now starts the unit immediately without requiring a second command
Add your user account to the libvirt group. Group membership is evaluated at login time. You must start a new session for the change to apply.
sudo usermod -aG libvirt $USER
# -aG appends the group without removing existing group memberships
# $USER expands to your current username in the active shell
Log out of your desktop session and log back in. If you are working over SSH, close the connection and open a new one. You can verify the group change without a full reboot by running id. The output should list libvirt among your active groups.
Network and storage configuration
Libvirt creates a default NAT network named default on first start. It assigns a private subnet, runs a DHCP server, and masquerades outbound traffic through the host interface. This works out of the box for most development VMs. If you need your VMs to appear as separate hosts on your local network, you must configure a bridged interface instead.
Edit the network XML definition in /etc/libvirt/qemu/networks/. Never edit files in /usr/share/libvirt/networks/. Those are package defaults and will be overwritten during dnf upgrade --refresh.
<network>
<name>br0</name>
<forward mode='bridge'/>
<bridge name='br0'/>
<!-- forward mode='bridge' tells libvirt to attach the virtual switch to a physical interface -->
<!-- bridge name must match the host network interface you want to share -->
</network>
Apply the network definition and start it. Libvirt will bring up the bridge and attach it to your physical NIC.
sudo virsh net-define /etc/libvirt/qemu/networks/br0.xml
sudo virsh net-start br0
sudo virsh net-autostart br0
# net-define registers the XML with the daemon without starting it
# net-start activates the bridge immediately
# net-autostart ensures the network comes up when libvirtd starts
Storage pools follow the same pattern. Libvirt expects VM disk images in /var/lib/libvirt/images/ by default. If you store images on a separate data drive, create a directory pool and set the correct ownership. QEMU processes run under the qemu user inside the libvirt namespace. Incorrect ownership causes immediate boot failures.
sudo mkdir -p /data/vms
sudo chown qemu:qemu /data/vms
# chown sets the owner and group to the qemu service account
# libvirt runs QEMU processes as qemu to enforce mandatory access controls
Define the pool and start it. Libvirt will track disk images in that directory and handle lifecycle management automatically.
sudo virsh pool-define-as vms data --target /data/vms
sudo virsh pool-start vms
sudo virsh pool-autostart vms
# pool-define-as registers a directory-based storage pool
# pool-start activates the pool for immediate use
# pool-autostart persists the pool across daemon restarts
Verify the installation
Check the daemon state first. The service should show active (running) and enabled.
systemctl status libvirtd
# status shows the current unit state, recent log lines, and dependency tree
# active (running) confirms the daemon is accepting connections on the socket
Confirm that hardware virtualization is recognized by the kernel. The lscpu command reports CPU flags directly from /proc/cpuinfo.
lscpu | grep Virtualization
# grep filters the output to show only the virtualization extension line
# Intel systems show 'VT-x'. AMD systems show 'AMD-V'
List the virtual networks. Libvirt creates a default NAT network named default on first start. It should show as active.
virsh net-list --all
# net-list queries the libvirt daemon for all defined network interfaces
# --all includes inactive networks so you can see the full inventory
Run journalctl -xeu libvirtd if you need to inspect recent daemon logs. The x flag adds explanatory hints and the e flag jumps to the end. Most sysadmins type this muscle-memory style when debugging service failures.
Common pitfalls and error messages
The most frequent failure is a permission error when running virsh or virt-install. The daemon refuses the connection because your session does not recognize the new group membership.
error: failed to connect to the hypervisor
error: no valid connection
error: Failed to connect socket to '/var/run/libvirt/libvirt-sock': Permission denied
Restart your login session. Do not try to work around it by running sudo virsh. Running libvirt commands as root bypasses the group policy and creates permission mismatches on VM disks.
SELinux denials appear when libvirt tries to access custom storage paths or non-standard network interfaces. The denial shows up in the journal with a one-line summary.
audit: type=1400 audit(1698765432.123:45): avc: denied { read } for pid=1234 comm="qemu-kvm" name="disk.img" dev="sda1" ino=98765 scontext=system_u:system_r:svirt_t:s0:c100,c200 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=0
Read the scontext and tcontext fields. They tell you which SELinux domain is blocked and which file label is causing the conflict. Fix the label with chcon or restorecon before disabling SELinux. Disabling SELinux breaks the isolation model and exposes the host to container escapes. Check journalctl -t setroubleshoot for a human-readable breakdown of the denial.
Another common issue is the missing virtualization flag in the BIOS. If lscpu returns nothing for virtualization, the CPU feature is disabled at the firmware level. Reboot into the firmware setup and enable Intel VT-x or AMD-V. Fedora cannot enable it from userspace.
If the KVM module fails to load, dmesg will show a warning about missing CPU support or a conflicting module.
kvm: disabled by bios
kvm: this module requires CPU virtualization extensions
The kernel refuses to initialize the hypervisor when the firmware blocks the instruction set. You must change the BIOS setting. No amount of userspace configuration will bypass this hardware lock.
When to use KVM versus other virtualization tools
Use KVM when you need full hardware isolation, near-native performance, and direct access to host devices through PCI passthrough. Use Docker or Podman when you only need process isolation and want to share the host kernel for faster startup times. Use VirtualBox when you require seamless guest additions, shared folders, and a graphical installer on Windows or macOS hosts. Use VMware Workstation when you need proprietary driver support or enterprise vSphere integration. Stay on the upstream KVM stack if you are running Fedora and want automatic security updates through the standard package manager.