You need a VM without the command-line headache
You downloaded a Fedora ISO to test the new release without wiping your laptop. You ran qemu-kvm from the terminal and got a wall of flags that looked like a spell from a dark wizard. Or maybe you need a sandbox for a risky package update and your browser sandbox isn't enough. virt-manager is the GUI that sits on top of KVM/QEMU and gives you a dashboard instead of a command line. It talks to libvirtd, so everything you do here maps directly to virsh commands if you ever decide to go CLI-only.
What is actually happening under the hood
virt-manager is a client application. It does not run the VMs itself. It sends XML configuration to libvirtd, the daemon that manages virtualization resources. libvirtd then hands off the heavy lifting to QEMU for emulation and KVM for hardware acceleration. This separation means you can manage VMs locally or over SSH using the same interface. The GUI is just a convenience layer. If the GUI breaks, virsh still works. If libvirtd dies, nothing works.
Think of libvirtd as the single source of truth. Every VM has an XML definition stored in /etc/libvirt/qemu/. virt-manager reads and writes that XML. The XML contains the CPU count, memory, disk paths, network interfaces, and boot order. When you click Start in the GUI, virt-manager tells libvirtd to parse the XML and spawn the QEMU process with the correct arguments. This architecture keeps the management layer decoupled from the hypervisor. You can swap the GUI for a CLI tool without touching the VM configuration.
Check the service status before blaming the GUI. If libvirtd is dead, virt-manager has nothing to talk to.
Install and verify the stack
Fedora ships virt-manager in the base repositories. The package pulls in the necessary dependencies, including the daemon and the hypervisor binary.
sudo dnf install virt-manager
# Installs the GUI client and pulls in libvirt-daemon, qemu-kvm, and dependencies.
# libvirt-daemon provides the libvirtd service that virt-manager talks to.
# qemu-kvm provides the actual hypervisor binary with KVM acceleration.
The daemon must be running for the manager to connect. Enable it to start on boot and start it immediately.
sudo systemctl enable --now libvirtd
# Enables the daemon to start on boot and starts it immediately.
# virt-manager will fail to connect if this service is inactive.
# The --now flag combines enable and start in one command.
Verify the service is active. If it is not, check the logs before proceeding.
sudo systemctl status libvirtd
# Checks the service state and shows recent log lines.
# Look for 'active (running)' in the output.
# If the service is failed, the log lines below will show the error.
Run systemctl status before restarting. The error message usually points to the missing config or permission issue.
Create a virtual machine
Open virt-manager from your application menu or run virt-manager in the terminal. Click File and then New Virtual Machine. Select Local install media and browse to your ISO file. Set the memory to at least 2048 MB for a Fedora Workstation guest. Allocate two CPU cores to keep the guest responsive. Create a new storage volume with 20 GB or more. Name the VM something recognizable and click Finish. The Anaconda installer will launch in a new window.
virt-manager creates qcow2 disk images by default. This format supports snapshots and thin provisioning. The file grows as you write data. If you need raw performance or plan to pass the disk through to another hypervisor, switch to raw format during creation. The default storage pool is default and lives in /var/lib/libvirt/images/. Do not move files manually in this directory. Libvirt tracks inventory via its internal database. Manual moves break the XML references and the VM will fail to start.
Name the VM by its purpose, not the ISO filename. You will forget what fedora-40-x86_64.iso was for in three weeks.
Manage hardware and take snapshots
Right-click a VM in the list to start, pause, or shut it down. Double-click the VM to open the graphical console. This uses SPICE by default, which gives better performance than VNC. Edit hardware only when the VM is powered off. Go to Edit and then Virtual Machine Details to add disks, change network interfaces, or adjust video settings. Changing hardware while the guest is running can cause kernel panics or data corruption.
Select the VM and open View then Snapshots. Click the camera icon to capture the current state. Use the revert button to roll back to a previous snapshot. This is useful before testing a risky kernel update inside the guest. Snapshots are stored as overlay files in the same directory as the disk image. They consume space as changes accumulate. Merge snapshots periodically if storage becomes tight.
Take a snapshot before the upgrade. If the guest kernel fails to boot, revert takes seconds.
Connect to remote hosts
virt-manager can manage remote hosts over SSH. Go to File and Add Connection. Choose QEMU/KVM as the hypervisor and SSH as the connection method. Enter the hostname and credentials. You can also connect from the command line using the URI syntax.
virt-manager --connect qemu+ssh://user@remote-host/system
# Opens the GUI connected to the remote libvirtd instance.
# The SSH key must be set up on the remote host for passwordless access.
# This avoids typing the password every time you open the manager.
Remote management requires libvirtd to be running on the remote host and the SSH daemon to allow connections. The remote host must have qemu-kvm installed. The GUI runs locally, so you can manage headless servers from your desktop.
Use SSH keys for remote connections. Password prompts break automation and slow down your workflow.
Networking and storage conventions
The default network uses NAT. Guests get private IP addresses and can reach the internet, but the host network cannot initiate connections to the guest. This is secure and works out of the box. If you need the guest to appear as a separate device on your LAN, you need a bridge. A bridge requires a network interface card and configuration on the host. virt-manager can create a bridge, but you must configure the host network manager to hand over the interface. This changes the host's network configuration. If you misconfigure the bridge, you can lose network access to the host. Use the default NAT network for most development work. Switch to a bridge only when you need LAN visibility or static IP assignment from your router.
Fedora uses NetworkManager. Libvirt integrates with NetworkManager for bridge management. Ensure the nm-libvirt plugin is loaded. It is enabled by default. If you manage interfaces manually with ifcfg files, you might conflict with NetworkManager. Stick to one method. Configuration for libvirt lives in /etc/libvirt/. The daemon reads these files. Do not edit files in /usr/lib/libvirt/. Those are shipped by packages and will be overwritten on update.
Trust the package manager. Manual file edits drift, snapshots stay.
Troubleshooting permissions and errors
If virt-manager refuses to start VMs or shows a permission error, your user account likely lacks access to the libvirt group. The daemon runs as root, but users in the libvirt group can manage VMs without sudo.
Error: permission denied
Unable to connect to libvirt.
Add your user to the group. You must log out and log back in for the group change to take effect. Running newgrp libvirt works for the current shell but does not fix the GUI session.
sudo usermod -aG libvirt $(whoami)
# Adds your user to the libvirt group.
# The -aG flag appends the group without removing existing groups.
# Logging out and back in reloads the group membership for the session.
If you see access denied errors and the group is correct, check SELinux. Fedora enforces SELinux by default. libvirtd has its own policy. Do not disable SELinux. Use journalctl to find denials.
sudo journalctl -t setroubleshoot
# Shows SELinux denial summaries generated by the setroubleshoot service.
# Each denial includes a one-line explanation and a suggested fix.
# Read the suggestion before applying any policy changes.
If the service fails to start, check the detailed logs.
sudo journalctl -xeu libvirtd
# Shows detailed logs for the libvirtd unit.
# The -x flag adds explanatory text for common errors.
# The -e flag jumps to the end of the log.
Run journalctl -xe first. Read the actual error before guessing.
When to use virt-manager versus alternatives
Use virt-manager when you want a graphical interface to manage VMs and prefer point-and-click workflows. Use virsh when you are scripting VM management or working on a headless server without a desktop environment. Use qemu-kvm directly when you need fine-grained control over emulation flags and do not want the abstraction layer of libvirt. Use virt-install when you want to create VMs from the command line while still leveraging libvirt for lifecycle management. Stay on virt-manager if you are a desktop user who needs occasional VM access and wants the simplest path to a working guest.