How to Install Fedora on a Virtual Machine (VirtualBox / VMware / GNOME Boxes)

Install Fedora on a virtual machine by creating a new VM, attaching the ISO, and following the installation prompts.

The scenario

You downloaded the Fedora Workstation ISO and your host machine is running fine, but you need a safe environment to test a new desktop workflow or a server configuration. You fire up VirtualBox, VMware, or GNOME Boxes, attach the image, and hit start. The installer loads, you click through the prompts, and the system reboots. Sometimes it boots straight into GNOME. Sometimes it drops you to a black screen or a GRUB prompt. The difference usually comes down to how the virtual hardware was configured before the first boot.

What the installer actually does

The Fedora installer, Anaconda, treats a virtual machine exactly like bare metal. It scans for block devices, partitions them, writes the bootloader, and drops the base system onto the virtual disk. The hypervisor sits between the guest and the host hardware, translating disk I/O, network packets, and display output. If the virtual hardware does not match what the Fedora kernel expects, the installer will stall or the first boot will fail. You are not just copying files. You are building a complete Linux system that relies on virtualized drivers and a correctly configured bootloader.

Think of the hypervisor as a translation layer. Your host CPU speaks x86-64, but the guest needs to believe it owns the silicon. The hypervisor intercepts privileged instructions and emulates or virtualizes them. Fedora ships with virtio drivers compiled into the kernel. These drivers talk directly to the hypervisor for disk and network access. If you assign a legacy IDE controller or an emulated Intel E1000 network card instead of the virtio equivalents, the system will boot, but performance will tank and you will see unnecessary kernel warnings.

Preparing the virtual hardware

Resource allocation sets the baseline for how the system behaves under load. Fedora Workstation runs smoothly with four gigabytes of RAM and two virtual CPUs. The desktop environment, background services, and a modern web browser will comfortably fit in that envelope. Allocate less and you will see swap thrashing. Allocate more only if you plan to run heavy workloads like container orchestration or local LLM inference.

Disk space requires a slightly different approach. Twenty gigabytes is the absolute minimum for a fresh install. The base system occupies roughly eight gigabytes. Package caches, journal logs, and user data will quickly consume the remainder. If you plan to keep the VM for more than a few weeks, start with forty gigabytes. Virtual disk files expand dynamically on most hypervisors, so you do not need to pre-allocate the full size.

Network configuration determines how the guest talks to the outside world. NAT (Network Address Translation) is the default on most hypervisors. The guest gets a private IP address and shares the host connection. Use NAT when you want isolation and do not need the guest to be reachable from other machines on your LAN. Use bridged networking when you need the guest to appear as a separate device on your physical network. Bridged mode requires your host network interface to support promiscuous mode or virtual switching. Pick the mode that matches your testing goal before you boot the installer.

Verifying the ISO before you boot

A corrupted download will cause Anaconda to fail during package extraction. The installer will print a hash mismatch error and abort. Verify the checksum before you attach the image to the virtual drive. This step takes ten seconds and saves you from debugging a broken installation later.

Here is how to verify the SHA256 checksum of the downloaded ISO against the official signature.

# Download the checksum file from the Fedora release page
curl -O https://fedoraproject.org/static/checksums/Fedora-Workstation-Live-x86_64-41-1.5-CHECKSUM

# Extract the expected hash for your specific ISO file
grep Fedora-Workstation-Live-x86_64-41-1.5.iso Fedora-Workstation-Live-x86_64-41-1.5-CHECKSUM | awk '{print $1}' > expected.sha256

# Calculate the actual hash of your downloaded file
sha256sum Fedora-Workstation-Live-x86_64-41-1.5.iso | awk '{print $1}' > actual.sha256

# Compare the two files. Exit code 0 means they match.
diff expected.sha256 actual.sha256

If diff returns no output, the file is intact. If it prints differences, delete the ISO and download it again. Do not attempt to mount or boot a mismatched image. The installer will refuse to proceed and print Error: Package download failed. Check your network connection or media integrity. The conflict is intentional. Read the next paragraph before forcing.

Running Anaconda

Attach the verified ISO to the virtual optical drive and power on the machine. The GRUB menu appears with a default timeout. Press Enter to boot the Live environment. Fedora uses a live ISO model for Workstation. The system boots into a fully functional desktop first. You launch the installer from the desktop by double-clicking the "Install to Hard Drive" icon. This design lets you test hardware compatibility, verify network connectivity, and run terminal commands before committing to disk writes.

Open a terminal in the Live environment and run lsblk to confirm the hypervisor exposed the virtual disk correctly. You should see a device like vda or sda with the size you allocated. If the disk is missing, shut down the VM and check the storage controller settings. Switch from IDE or SATA to VirtIO SCSI if your hypervisor supports it. The virtio-scsi driver provides lower latency and better I/O scheduling.

Launch the installer and proceed through the destination selection. Choose automatic partitioning for a standard desktop setup. The installer will create a Btrfs root volume with subvolumes for /, /home, and /var. This is the Fedora default and enables built-in snapshots. If you need ext4 for compatibility with older backup tools, switch the file system type manually. The installer will warn you that snapshots will be unavailable. Accept the warning if your workflow requires it.

Set the root password and create a user account. The installer will begin downloading packages if you selected the default "Download latest updates" option. This step requires working DNS and HTTP access. If the download stalls, click the network icon in the top right, verify the connection, and resume. The installation writes the base system, configures GRUB, and installs the bootloader to the virtual disk. When it finishes, click Reboot.

First boot and post-install verification

The first boot drops you into the GNOME login screen. Log in with the user account you created. Open a terminal and run a system update immediately. The Live ISO ships with packages frozen at release time. The repositories contain newer kernel updates, security patches, and bug fixes.

Here is the standard post-install update sequence.

# Refresh metadata and apply all available updates
sudo dnf upgrade --refresh

# Clear cached package metadata to free disk space
sudo dnf clean all

# Verify the running kernel matches the installed version
uname -r

The --refresh flag forces dnf to download fresh repository metadata instead of relying on cached timestamps. This is the normal weekly maintenance command. dnf system-upgrade is for crossing major Fedora releases. They are different commands. Do not conflate them.

Check the journal for hardware or driver warnings. The x flag adds explanatory text and the e flag jumps to the end. Most sysadmins type journalctl -xeu <unit> muscle-memory style. Run it without a unit filter to scan the entire boot sequence.

# Review recent boot logs for warnings or failed units
journalctl -xe --boot=0

Scan the output for [FAILED] or Warning: lines. NetworkManager usually handles virtual interfaces automatically. If you see repeated connection timeouts, verify that the virtual network adapter is set to NAT or Bridged in the hypervisor settings. Config files in /etc/ are user-modified. Files in /usr/lib/ ship with the package. Edit /etc/. Never edit /usr/lib/. SELinux denials show up in journalctl -t setroubleshoot with a one-line summary. Read those before disabling SELinux.

Common pitfalls and error messages

A black screen after the GRUB menu usually means the virtual display driver is not loading. Fedora defaults to the virtio-gpu driver for virtual machines. If your hypervisor emulates a legacy VGA card instead, the kernel will fall back to a low-resolution framebuffer that often fails to initialize the desktop compositor. Switch the display adapter to VirtIO or VMware SVGA in the VM settings. Reboot before you debug. Half the time the symptom is gone.

Network failures during installation appear as Connection timed out or Could not resolve host. The Live environment uses NetworkManager, which sometimes struggles with bridged interfaces that lack DHCP. Switch to NAT temporarily, complete the installation, and configure bridged networking after the first boot. Run nmcli device status to see which interfaces are recognized. If the virtual NIC is missing, check the hypervisor network filter or firewall rules that might be blocking virtual traffic.

Disk write errors during Anaconda usually point to a misconfigured storage controller. Legacy IDE emulation works but lacks the virtio-blk optimizations. The installer will still complete, but you will see I/O error messages in the journal later. Switch to VirtIO SCSI or VirtIO Block. The kernel includes the drivers by default. No additional packages are required.

If the boot menu is gone, GRUB rescue is your friend, not your enemy. The bootloader configuration lives in /boot/grub2/grub.cfg. Manual edits to this file drift across kernel updates. Trust the package manager. Run sudo grub2-mkconfig -o /boot/grub2/grub.cfg to regenerate it safely. Snapshot the system before the upgrade. Future-you will thank you.

Choosing your hypervisor

Use GNOME Boxes when you want a zero-configuration experience that integrates with your host desktop. Use VirtualBox when you need cross-platform compatibility and snapshot management without installing extra dependencies. Use VMware Workstation Player when you require 3D acceleration support and advanced virtual network segmentation. Use KVM with virt-manager when you want native Linux performance and direct access to libvirt APIs. Stay on the upstream Workstation if you only deviate from the defaults occasionally.

Where to go next