You need a quick VM and the terminal feels like overkill
You downloaded a Linux ISO to test a new desktop environment. Or you need a clean, isolated environment to run a sketchy script without touching your host filesystem. You want it up in five minutes. You open the terminal, type qemu-system-x86_64, and immediately drown in device flags, network backends, and disk format arguments. You need a GUI that gets out of your way but still respects the underlying virtualization stack. GNOME Boxes is that tool. It ships with Fedora Workstation. It wraps QEMU and libvirt in a single window. You click a button, you get a running system.
What GNOME Boxes actually does under the hood
Boxes does not invent virtualization. It delegates to qemu-kvm for hardware emulation and libvirt for lifecycle management. Think of libvirt as the traffic controller and QEMU as the engine. Boxes just draws the dashboard. When you create a VM, Boxes writes an XML definition to ~/.local/share/gnome-boxes/, tells libvirt to allocate a qcow2 disk image, and passes the ISO path to the QEMU process. The hypervisor runs in userspace but leverages kernel-level KVM acceleration. Your host CPU handles the heavy lifting. The guest OS thinks it has its own hardware. It does not. It shares the host memory, CPU time slices, and a virtualized storage controller.
This architecture matters because it means Boxes inherits every strength and limitation of the standard Fedora virtualization stack. You get live migration support, snapshot capabilities, and hardware passthrough if you configure it manually. You also get the same permission model and SELinux contexts that every other libvirt tool uses. Config files in /etc/libvirt/ are user modified. Files in /usr/share/libvirt/ ship with the package. Edit /etc/. Never edit /usr/share/. Boxes respects this boundary automatically, but knowing it saves you when you eventually need to tweak network bridges or storage pools.
Run journalctl -xe before guessing. The x flag adds explanatory text and the e flag jumps to the end. Most sysadmins type journalctl -xeu libvirtd muscle memory style when a VM refuses to start.
Setting up your first virtual machine
Boxes is preinstalled on Fedora Workstation. If your system is minimal or you are on Server, install it with the package manager.
sudo dnf install gnome-boxes -y
# --refresh forces dnf to fetch fresh metadata from the repos
# -y skips the confirmation prompt for a clean install
gnome-boxes
# Launches the GUI. No daemon restart required.
Open the application from your menu or run the command above. Click the plus button to create a new virtual machine. You will see two primary options. Select Import an ISO image and browse to your installer file. Or choose Use a cloud image for preconfigured systems that skip the graphical installer entirely. Cloud images are smaller, boot faster, and are ideal for server testing. ISOs give you full control over partitioning and package selection during installation.
Boxes will ask for disk space and memory. The defaults are conservative. Allocate at least 20 gigabytes for a modern desktop ISO. Give it 4 gigabytes of RAM if your host has 16 or more. Boxes creates a qcow2 file by default. This format supports thin provisioning. The file starts small and grows as you write data. It also supports snapshots. You do not need to preallocate a fixed size unless you are running a database workload that demands predictable I/O latency.
Click Create. Boxes hands the configuration to libvirt, which spawns the QEMU process. The guest boots from the ISO. You see the installer or the cloud-init login prompt. Proceed through the guest setup normally. Boxes keeps the window focused on the guest display. The host desktop remains responsive.
Reboot before you debug. Half the time the symptom is gone.
Verify the VM is running correctly
Boxes hides the management layer, but you should verify that the VM is actually using hardware acceleration. Software emulation runs at a fraction of the speed and will make your system unusable for anything beyond basic testing.
lscpu | grep -i kvm
# Checks if the kernel exposes KVM modules
# Look for "KVM hardware acceleration: yes"
virsh list --all
# Lists all libvirt domains managed by Boxes
# Boxes names domains with a UUID or the ISO filename
systemctl status libvirtd
# Confirms the daemon is active and handling VM lifecycle
If lscpu shows KVM acceleration as no, your CPU does not support virtualization extensions, or they are disabled in the firmware. Enter your BIOS or UEFI setup and enable Intel VT-x or AMD-V. Save and reboot. Boxes will automatically switch to hardware acceleration on the next launch.
You can also verify that the disk image is using qcow2 and that snapshots are available. Boxes stores metadata in ~/.local/share/gnome-boxes/. The actual disk files live in ~/.local/share/libvirt/images/. Do not move these files manually. libvirt tracks them by UUID. Moving them breaks the domain definition and triggers a missing backing file error.
Trust the package manager. Manual file edits drift, snapshots stay.
Common pitfalls and what the error looks like
Virtualization stacks are mature, but they still fail when hardware, permissions, or configuration drift out of sync. Boxes surfaces libvirt errors directly in the window. Read the actual error before guessing.
The most common failure is a CPU model mismatch. Older hosts or misconfigured BIOS settings can cause QEMU to reject the default CPU type. You will see this in the Boxes window:
Error: Internal error: cannot load CPU model
This means the guest XML requests a CPU feature your host cannot emulate. Open a terminal and run virsh edit <domain-name>. Change the <cpu mode='host-passthrough'/> line to <cpu mode='custom' model='qemu64'/>. Save the file. Restart the VM. The custom model strips advanced instructions and falls back to a baseline that runs everywhere.
Another frequent issue is a full qcow2 disk. Thin provisioning hides the real size until the host filesystem runs out of space. When the disk hits its virtual limit, QEMU panics:
Failed to start virtual machine: operation failed: QEMU unexpectedly terminated
Check the actual file size with ls -lh ~/.local/share/libvirt/images/. If it matches your virtual limit, expand it with qemu-img resize <file.qcow2> +10G. Boxes will recognize the new capacity on the next boot.
SELinux denials occasionally appear when you mount host directories into the VM or use custom ISO paths outside your home directory. Do not disable SELinux. Check the audit log first:
sudo ausearch -m avc -ts recent
# Filters for Access Vector Cache denials since the last boot
# Look for "type=AVC" lines referencing qemu or libvirt
sudo restorecon -Rv ~/.local/share/libvirt/
# Resets context labels to the package defaults
Run journalctl -xe first. Read the actual error before guessing.
When to use Boxes versus other tools
Use GNOME Boxes when you want a zero-configuration GUI that handles ISO installation and cloud images without exposing XML files. Use virt-manager when you need to configure virtual networks, attach host USB devices, or manage multiple storage pools. Use the QEMU command line when you are testing kernel patches, debugging boot parameters, or building automation scripts that require deterministic flags. Use Podman when you only need application isolation and do not require a full guest operating system. Stay on Boxes if you only deviate from the defaults occasionally.