You need a VM, but Fedora says no
You just finished a clean Fedora install. You need to spin up a Windows VM for testing, or maybe an older Linux release that doesn't run on your new hardware. You open the terminal, type sudo dnf install VirtualBox, and get a package not found error. The official Fedora repos don't carry it. You are left staring at a blank screen, wondering how to get a widely used hypervisor running on a distribution that prides itself on free software.
The missing package is intentional. Fedora ships with a different virtualization stack by default. Getting VirtualBox working requires pulling a third-party repository, compiling a proprietary kernel module, and adjusting user permissions. The process is straightforward once you understand the moving parts.
Why Fedora leaves it out
Fedora ships with QEMU and KVM as the default virtualization stack. They are fully open source and integrated directly into the Linux kernel. VirtualBox relies on a proprietary kernel module and a separate user-space daemon. The licensing difference is why you will not find it in the default repositories.
Installing VirtualBox means pulling a third-party RPM, ensuring your kernel headers match the running kernel, and letting DKMS compile the proprietary driver on the fly. DKMS stands for Dynamic Kernel Module Support. It watches your kernel version and rebuilds out-of-tree modules whenever you update the kernel. Without DKMS, every kernel upgrade would break your virtual machines until you manually recompiled the driver.
Run dnf upgrade --refresh before installing third-party software. It forces the package manager to check for updated metadata and prevents dependency conflicts with stale cache files.
Add the official repository
The most reliable method is to add the official Oracle repository. Downloading a single RPM from a URL works, but it leaves you without automatic updates and breaks your package manager's dependency tracking. The repository method keeps VirtualBox aligned with the rest of your system.
Here is how to import the GPG key and register the repository for your architecture.
# Import the official Oracle signing key so dnf can verify packages
sudo rpm --import https://www.virtualbox.org/download/oracle_vbox_2016.asc
# Register the repository configuration for your Fedora release
sudo rpm --import https://www.virtualbox.org/download/oracle_vbox.asc
# Create the repo file in the dnf configuration directory
sudo dnf config-manager --add-repo https://download.virtualbox.org/virtualbox/rpm/fedora/virtualbox.repo
# Refresh the metadata cache to recognize the new source
sudo dnf makecache
The repository file lands in /etc/yum.repos.d/. Never edit files in /usr/lib/ or /usr/share/. Those directories ship with packages and get overwritten on updates. Keep all user modifications in /etc/.
Install and compile the kernel modules
With the repository active, you can install the hypervisor and its dependencies. The package manager will pull the core application, the extension pack, and the DKMS framework if it is missing.
Here is how to install the package and trigger the initial module build.
# Install the hypervisor and required kernel development headers
sudo dnf install VirtualBox-7.0 kernel-devel kernel-headers
# Load the newly compiled kernel module into the running kernel
sudo modprobe vboxdrv
# Enable the module to load automatically on future boots
sudo systemctl enable vboxdrv.service
The kernel-devel package is mandatory. DKMS needs the exact header files that match your running kernel to compile the proprietary driver. If you recently upgraded the kernel but haven't rebooted, the headers might not match. Reboot before you debug. Half the time the symptom is gone.
Secure Boot will block the module if it is not signed. You will see a Key was rejected by service message in the journal. You must either disable Secure Boot in your firmware settings or enroll a Machine Owner Key (MOK) using mokutil. Disabling Secure Boot is faster for testing. Enrolling a key is safer for production workstations.
Grant hardware access to your user
VirtualBox needs direct access to CPU virtualization extensions and USB controllers. The hypervisor restricts this access to a dedicated group called vboxusers. If you skip this step, the GUI will launch but refuse to start any machine.
Here is how to add your current user to the group and verify the change.
# Add your username to the vboxusers group without removing existing groups
sudo usermod -aG vboxusers $USER
# Verify the group membership in the current shell session
id -nG
# Log out and back in to apply the new group credentials
# (Group changes do not apply to already running processes)
The -aG flag appends the group. Omitting -a replaces all your existing groups and locks you out of sudo. Always use -aG when modifying group membership.
Verify the installation
Run the command-line manager to confirm the hypervisor is ready. The output should show the installed version and confirm that the kernel module is loaded.
Here is how to check the version and verify the driver state.
# Print the installed VirtualBox version and build information
VBoxManage --version
# Check the systemd service state and recent journal entries
systemctl status vboxdrv.service
# Confirm the kernel module is active and not blacklisted
lsmod | grep vbox
If systemctl status shows active (exited), the service ran successfully and loaded the module. The service exits because its only job is to insert the module at boot. It does not stay running like a daemon. Run journalctl -xe if you need to trace a failure. The x flag adds explanatory text and the e flag jumps to the end. Most sysadmins type journalctl -xeu vboxdrv.service muscle-memory style.
Common pitfalls and what the error looks like
The installation fails in three predictable ways. Each one has a specific error string and a direct fix.
The first failure happens when DKMS cannot find matching headers. You will see Error! Your kernel headers for kernel 6.x.x-xxx-generic cannot be found. Install kernel-devel and reboot into the matching kernel. The header package name must exactly match uname -r.
The second failure occurs when Secure Boot rejects the unsigned module. The journal prints vboxdrv: loading out-of-tree module taints kernel. followed by a signature verification failure. Disable Secure Boot in the firmware menu or use mokutil --import to sign the module. Trust the package manager. Manual file edits drift, snapshots stay.
The third failure is a permissions error when starting a VM. The GUI shows Failed to open a session for the virtual machine. with a VERR_SUPDRV_NO_RAW_MODE code. Your user is not in the vboxusers group, or you haven't logged out since adding the group. Log out completely and log back in. Group changes require a fresh session.
SELinux denials are rare but possible. Check journalctl -t setroubleshoot for one-line summaries. Do not disable SELinux to fix a VirtualBox error. Fix the context or policy instead.
When to use VirtualBox versus other hypervisors
Use VirtualBox when you need cross-platform compatibility and easy USB passthrough for Windows or macOS guests. Use KVM with QEMU when you want near-native performance and full integration with Fedora's kernel virtualization stack. Use GNOME Boxes when you only need quick, disposable Linux VMs for testing and don't care about advanced networking. Use VMware Workstation Player when you require 3D acceleration support that VirtualBox struggles to provide. Stay on the default QEMU/KVM stack if you are running servers and want zero proprietary dependencies.