You need a VM and the terminal feels too abstract
You downloaded a Fedora ISO to test a new release, or you need an isolated sandbox to compile untrusted code. The terminal handles quick tasks well, but managing disk images, network bridges, and console access through raw commands becomes tedious fast. You want a graphical interface that talks directly to the hypervisor without hiding the underlying configuration. virt-manager gives you that interface. It exposes the full libvirt API through a GTK window, letting you allocate resources, attach storage, and monitor logs without memorizing XML syntax.
What virt-manager actually controls
virt-manager is not a hypervisor. It is a client for libvirt. libvirt is the daemon that translates your requests into KVM and QEMU instructions. KVM handles CPU virtualization inside the Linux kernel. QEMU emulates the hardware devices. virt-manager just draws the boxes and buttons. When you click create, the tool writes an XML definition to /etc/libvirt/qemu/ and tells libvirtd to parse it.
Think of it like a construction site. KVM is the foundation crew that pours the concrete. QEMU is the carpentry team that frames the walls and installs the windows. libvirt is the foreman who reads the blueprints and tells each crew what to do. virt-manager is the architect's office where you draw the blueprints. If the foreman rejects the plans, the GUI will show an error. If you understand who holds which tool, you stop guessing why a setting disappeared after a reboot.
Run systemctl status libvirtd before you open the GUI. A stopped daemon makes every button look broken.
Install and configure the stack
Fedora ships with KVM and QEMU in the base repository. You only need to pull in the management layer and configure user permissions. The default installation runs libvirt as a system service. Your regular user account needs explicit group membership to talk to the daemon without sudo.
Here is how to install the package and set up the required groups.
sudo dnf install virt-manager libvirt qemu-kvm -y
# --refresh forces dnf to check for updated metadata before resolving dependencies
# libvirt provides the daemon and CLI tools, qemu-kvm provides the actual hypervisor backend
sudo usermod -aG libvirt,kvm $USER
# -aG appends the groups without removing existing ones
# libvirt grants API access, kvm grants direct /dev/kvm device access
newgrp libvirt
# newgrp applies the group change to the current shell session immediately
Fedora's release cadence is six months. Run dnf upgrade --refresh weekly to keep the hypervisor stack patched. dnf system-upgrade is reserved for crossing major releases. They are different commands. Do not conflate them.
The default virtual network uses NAT routing through virbr0. It works out of the box but requires manual port forwarding if you need to reach the guest from outside the host. Enable the network so it starts automatically.
sudo virsh net-autostart default
# Tells libvirt to start the default NAT network on every boot
sudo virsh net-start default
# Activates the network immediately without rebooting
Config files in /etc/libvirt/ are user-modified. Files in /usr/lib/libvirt/ ship with the package. Edit /etc/. Never edit /usr/lib/. Manual file edits drift, snapshots stay.
Create the virtual machine
Launch virt-manager from your application menu or by running virt-manager in a terminal. The main window shows connected URIs. You will see QEMU/KVM listed under the local host. Double-click it to connect. If the connection fails, check your group membership and restart the session.
Click the computer-and-plus icon to start the wizard. Select Local install media (ISO image or CDROM) and click Forward. Browse to your downloaded ISO file. The wizard will attempt to auto-detect the operating system. If it guesses wrong, manually select the correct family and version from the dropdown. Auto-detection reads the ISO metadata, but older or heavily modified images sometimes hide it.
Set your desired RAM and CPU count. Leave the CPU model on host-passthrough unless you plan to migrate the VM between machines with different CPU generations. Host passthrough gives the guest direct access to the host's instruction sets, which improves performance and reduces scheduling overhead.
Create a new virtual disk. The wizard defaults to qcow2 format. Keep it. qcow2 supports thin provisioning, snapshots, and compression. Raw images are faster for sequential I/O but consume full disk space immediately and lack snapshot support. Set the disk size to your target capacity. The file will only grow as you write data inside the guest.
Name the virtual machine and click Finish. The installation console opens automatically. Proceed with the guest OS installer as you would on bare metal. virt-manager streams the serial console output directly from QEMU.
Reboot before you debug. Half the time the symptom is gone.
Verify the VM is running correctly
The GUI shows a green power indicator when the domain is active. Verify the state from the terminal to confirm libvirt recognizes it.
virsh list --all
# --all shows both running and shut-down domains
# Look for your VM name in the output with a 'running' state
virsh dominfo <vm-name>
# Displays memory allocation, vCPU count, and disk path
Check the guest network connectivity. The default NAT network assigns addresses via DHCP on the 192.168.122.0/24 subnet. Open the VM console in virt-manager and run ip addr inside the guest. You should see an address in that range. Ping the host gateway at 192.168.122.1 to confirm routing.
If the console shows a black screen or hangs at boot, check the host logs. journalctl -xeu libvirtd reads better than journalctl alone. The x flag adds explanatory text and the e flag jumps to the end. Most sysadmins type journalctl -xeu <unit> muscle-memory style. Look for qemu or kvm errors in the output. SELinux denials show up in journalctl -t setroubleshoot with a one-line summary. Read those before disabling SELinux.
Run journalctl -xe first. Read the actual error before guessing.
Common pitfalls and error messages
The virt-manager connection dialog will refuse to authenticate and print error: failed to connect to the hypervisor. This almost always means your user account lacks the libvirt group membership, or you opened the GUI before running newgrp. Log out and log back in, or run newgrp libvirt in the terminal before launching the app.
If the wizard fails during disk creation and prints Error: Cannot access storage file '/var/lib/libvirt/images/guest.qcow2': Permission denied, the libvirt daemon is running under the qemu user but your shell created the directory with restrictive permissions. Fix the ownership and SELinux context.
sudo chown -R qemu:qemu /var/lib/libvirt/images
# Ensures the libvirt service can read and write the disk directory
sudo restorecon -Rv /var/lib/libvirt/images
# Resets SELinux labels to the default policy for virtual machine storage
Another frequent issue appears when you attach a second network interface. The GUI will show Error: Requested operation is not valid: network 'default' is not active. The NAT network stopped after a host reboot or a manual virsh net-destroy. Start it again with sudo virsh net-start default. Always verify the network state before adding interfaces.
If the boot menu is gone, GRUB rescue is your friend, not your enemy.
When to use virt-manager versus alternatives
Use virt-manager when you want a graphical interface that exposes the full libvirt API without hiding XML configuration. Use virsh when you are scripting VM creation, managing clusters, or working over SSH without X11 forwarding. Use Cockpit when you need a web-based dashboard that handles monitoring, storage pools, and user management alongside virtual machines. Use cloud-init with Terraform or Ansible when you are provisioning dozens of identical guests and need reproducible infrastructure. Stay on the upstream Workstation if you only deviate from the defaults occasionally.
Trust the package manager. Manual file edits drift, snapshots stay.