Install Vagrant and VirtualBox on Fedora 45 / 44

Fedora still packages Vagrant, but its build dates from December 2022 and refuses to drive VirtualBox 7.2. HashiCorp’s own Vagrant on Fedora supports that release, yet HashiCorp’s repository has no Fedora 45 tree, and Fedora’s official Vagrant box, given two CPUs under VirtualBox, boots so slowly that vagrant up gives up before SSH answers. None of those failures says what is actually wrong.

Original content from computingforgeeks.com - post 4703

This guide installs Vagrant with VirtualBox and with libvirt (KVM) on Fedora 45 and 44, works around each trap, and boots one provisioned guest under both providers from a single Vagrantfile. Every command below was run on Fedora 45 and Fedora 44 lab VMs in October 2026 with Vagrant 2.4.9 from HashiCorp, Fedora’s packaged Vagrant 2.3.4, VirtualBox 7.2 and libvirt.

Pick a Vagrant build and a provider

Which Vagrant you install decides which provider you can use, because Fedora’s package and HashiCorp’s package are two different programs that share a name. Fedora’s vagrant runs on the system Ruby and comes with a matching vagrant-libvirt package. HashiCorp’s ships its own Ruby under /opt/vagrant, knows about current VirtualBox releases, and needs the libvirt plugin built against it. We ran every combination on both releases, and this is what each one did:

Vagrant build	Provider	Fedora 45	Fedora 44
Fedora repos, 2.3.4	libvirt (vagrant-libvirt 0.11.2 RPM)	Works, qemu:///session	Works, qemu:///session
Fedora repos, 2.3.4	VirtualBox 7.2	Refused: unsupported version	Refused: unsupported version
HashiCorp repo, 2.4.9	VirtualBox 7.2	Works (repo pinned to the 44 tree, VirtualBox from RPM Fusion)	Works (Oracle’s VirtualBox repo)
HashiCorp repo, 2.4.9	libvirt (vagrant-libvirt 0.12.2 plugin)	Works, qemu:///system	Works, qemu:///system

Pick the build from the guests you plan to run, because you cannot have both builds at once: both packages are named vagrant and install /usr/bin/vagrant.

• KVM guests only: Fedora’s vagrant-libvirt package
• VirtualBox guests: HashiCorp’s Vagrant
• Both hypervisors: HashiCorp’s Vagrant plus the vagrant-libvirt plugin

Each path uses different sections. The KVM-only path runs from the Fedora repos install through “Boot a libvirt guest” and stops there. The VirtualBox path skips the Fedora repos install, the libvirt box and the libvirt boot: install HashiCorp’s Vagrant, create the Vagrantfile from “Write a Vagrantfile for both providers”, then follow the two VirtualBox sections, which add their own box. The both-hypervisors path is the VirtualBox path plus “Add libvirt to HashiCorp’s Vagrant”.

Fedora’s packages are the easy KVM route: one dnf command, no third-party repository, and guests run as your user without any group changes. The third option is the setup we’d run on a workstation, because Fedora’s 2.3.4 will not see VirtualBox 7.2 support unless Fedora moves to a newer Vagrant, so every VirtualBox user ends up on HashiCorp’s build anyway.

Prerequisites

Vagrant itself is small. The weight comes from the hypervisor and the boxes, so plan disk space for those:

• Fedora 45 or Fedora 44 on x86_64, with VT-x or AMD-V enabled in firmware
• A user with sudo rights
• About 1 GB for the libvirt stack, 0.8 GB per libvirt box (plus a second copy in the libvirt storage pool) and 1.1 GB per VirtualBox box
• 2 GB of free RAM per guest with the Vagrantfile used here

Update the system and reboot into the newest kernel first. VirtualBox builds its kernel module against the running kernel, and kernel-devel-$(uname -r) only resolves when the kernel you are running is the one in the repos. The post-install steps for Fedora 45 cover the update and reboot. Then confirm the CPU exposes hardware virtualization.

grep -cE "vmx|svm" /proc/cpuinfo
lsmod | grep -E "^kvm"

A non-zero count means the flag is there, one per logical CPU. Fedora loads the KVM modules at boot whenever the flag exists, so both lines should show up even before you install anything:

8
kvm_intel             557056  0
kvm                  1568768  1 kvm_intel

A count of 0 means virtualization is off in firmware, or you are inside a VM whose hypervisor does not pass it through. Neither provider will start a guest until that is fixed, because both rely on the same VT-x or AMD-V extensions, so check this before you install a gigabyte of packages.

Install Vagrant with libvirt from Fedora’s repos

The vagrant-libvirt package pulls in Vagrant, QEMU and the whole libvirt stack, so this one command is the entire KVM install. It is not small: 475 packages and 950 MiB on Fedora 45, 502 packages and 983 MiB on Fedora 44, about two and a half minutes on each lab VM:

sudo dnf install -y vagrant-libvirt

Check what you have. The plugin is listed as a system plugin, which means it lives in the RPM rather than in your ~/.vagrant.d:

vagrant --version
vagrant plugin list

Both releases installed the same versions:

Vagrant 2.3.4
vagrant-libvirt (0.11.2, system)

The install enables libvirt’s sockets but does not start them, so until the next reboot vagrant up dies with Failed to connect socket to '/var/run/libvirt/virtqemud-sock-ro'. Starting only virtqemud.socket is not enough either, because the read-only socket Vagrant opens first is a separate unit. Start every modular daemon’s three sockets in one loop, the pattern libvirt documents for its modular daemons:

for drv in qemu network nodedev nwfilter secret storage interface; do sudo systemctl enable --now virt${drv}d{,-ro,-admin}.socket; done

Fedora’s vagrant-libvirt package defaults to qemu:///session, so guests run as your user, disks land in ~/.local/share/libvirt/images, and you do not need the libvirt group or a password prompt. The trade-off is that root’s view of libvirt never shows these guests, which surprises people the first time sudo virsh list comes back empty while a guest is running. Use virsh -c qemu:///session list instead.

Add Fedora’s official Vagrant box

Fedora publishes Vagrant boxes for libvirt and VirtualBox next to its cloud images, with checksums, and we’d use those over a community box on Fedora’s Vagrant for a specific reason. Our first attempt used cloud-image/fedora-43 from the public registry, and the guest sat at SeaBIOS’s “Booting from Hard Disk…” until vagrant up timed out. The box metadata Vagrant had saved explained it:

uname -m
cat ~/.vagrant.d/boxes/cloud-image-VAGRANTSLASH-fedora-43/1.6.0/libvirt/metadata.json

On an x86_64 host, Vagrant had downloaded the arm64 build:

x86_64
{
  "architecture": "arm64",
  "provider": "libvirt",
  "format": "qcow2",
  "virtual_size": 10
}

Architecture support arrived in Vagrant 2.4.0, so Fedora’s 2.3.4 does not know the field exists and takes the first libvirt build a multi-arch box lists. Any registry box that publishes arm64 and amd64 builds under one name can do this to you. Fedora’s own box files are single-architecture, so the problem goes away. Look up the current libvirt box and its SHA-256 from the release’s checksum file, then add it under a short name:

IMG_URL=https://dl.fedoraproject.org/pub/fedora/linux/releases/44/Cloud/x86_64/images
BOX=$(curl -fsSL ${IMG_URL}/ | grep -oE "Fedora-Cloud-Base-Vagrant-libvirt-[^\"]+\.box" | head -1)
SUMS=$(curl -fsSL ${IMG_URL}/ | grep -oE "Fedora-Cloud-[^\"]+-CHECKSUM" | head -1)
SHA=$(curl -fsSL ${IMG_URL}/${SUMS} | awk -v b="($BOX)" '$2==b {print $4}')
echo "$BOX $SHA"
vagrant box add --name fedora/44-cloud-base --checksum-type sha256 --checksum "$SHA" ${IMG_URL}/${BOX}

Vagrant verifies the download against the checksum before it registers the box, which took under a minute for the 801 MB image:

Fedora-Cloud-Base-Vagrant-libvirt-44-1.7.x86_64.vagrant.libvirt.box 4695d5ef2bfcc882649b98de0c545d04671d2064f6609e7e68e606718c8333dc
    box: Calculating and comparing box checksum...
==> box: Successfully added box 'fedora/44-cloud-base' (v0) for 'libvirt'!

The Fedora 44 box runs fine on a Fedora 45 host, since the guest’s release has nothing to do with the host’s. We ran it on both hosts, so the guest release is your choice rather than a requirement. Once Fedora lists Vagrant boxes under releases/45/Cloud, change 44 to 45 in IMG_URL and in the box name if you want a Fedora 45 guest.

Write a Vagrantfile for both providers

One Vagrantfile can carry settings for libvirt and VirtualBox, and Vagrant applies only the block for the provider you start with. That means the same file serves both halves of this guide, so you have one place to change memory or CPUs. Create a project directory and open the file.

mkdir -p ~/vagrant/fedora-lab && cd ~/vagrant/fedora-lab
vim Vagrantfile

This is the exact file we ran on both hosts and both providers. The shell provisioner installs nginx in the guest, which gives you something to check from outside once the machine is up:

Vagrant.configure("2") do |config|
  config.vm.box = "fedora/44-cloud-base"
  config.vm.hostname = "web01"

  config.vm.provider "libvirt" do |lv|
    lv.memory = 2048
    lv.cpus = 2
  end

  config.vm.provider "virtualbox" do |vb|
    vb.memory = 2048
    vb.cpus = 2
    vb.customize ["modifyvm", :id, "--ioapic", "on", "--paravirtprovider", "kvm"]
  end

  config.vm.provision "shell", inline: <<-SHELL
    dnf -y install nginx
    systemctl enable --now nginx
  SHELL
end

The vb.customize line is not decoration. Fedora’s VirtualBox box registers as “Other Linux (64-bit)” with the I/O APIC switched off, and the VirtualBox manual says the I/O APIC is required for more than one virtual CPU. Without that line a two-CPU guest crawls, as the VirtualBox section below shows.

Boot a libvirt guest

Start the machine with the libvirt provider. Vagrant creates the domain, waits for a DHCP lease on libvirt’s virbr0 network, swaps the insecure key for a new one, copies the project directory into the guest with rsync and runs the provisioner.

vagrant up --provider=libvirt

The important lines are the SSH address and “Machine booted and ready”. The whole run, nginx install included, took 1m09s on Fedora 45 and 1m43s on Fedora 44:

==> default:  -- Memory:            2048M
==> default:  -- Base box:          fedora/44-cloud-base
==> default:  -- Image(vda):        /home/josphat/.local/share/libvirt/images/fedora-lab_default.img, virtio, 5G
==> default: Starting domain.
==> default: Waiting for domain to get an IP address...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 192.168.122.251:22
    default: SSH username: vagrant
    default: SSH auth method: private key
    default: Key inserted! Disconnecting and reconnecting using new SSH key...
==> default: Machine booted and ready!
==> default: Setting hostname...
==> default: Rsyncing folder: /home/josphat/vagrant/fedora-lab/ => /vagrant
==> default: Running provisioner: shell...

Confirm the guest is the release you expect and that the provisioner did its job.

vagrant status
vagrant ssh -c "cat /etc/fedora-release; systemctl is-active nginx; curl -sI localhost | head -1"

A running domain, a Fedora 44 guest and nginx answering on port 80:

Current machine states:

default                   running (libvirt)

The Libvirt domain is running. To stop this machine, you can run
`vagrant halt`. To destroy the machine, you can run `vagrant destroy`.
Fedora release 44 (Forty Four)
active
HTTP/1.1 200 OK

If KVM is all you need, you can stop here, because nothing later in the guide changes the libvirt path you just set up. The rest moves to HashiCorp’s Vagrant, which you need for VirtualBox, and that switch removes this libvirt provider unless you add the plugin back. After the switch, HashiCorp’s Vagrant can no longer halt or destroy this guest, so if you are continuing to HashiCorp’s Vagrant, remove it first while Fedora’s build still can:

cd ~/vagrant/fedora-lab && vagrant destroy -f

The later sections each use their own project directory, so a machine left in fedora-lab by one provider never blocks the other.

Install HashiCorp’s Vagrant on Fedora 45 and 44

Fedora’s 2.3.4 is the reason you need HashiCorp’s build. Its VirtualBox provider stops at 7.0, and Vagrant only gained VirtualBox 7.2 support in 2.4.9. With Fedora’s Vagrant and VirtualBox 7.2 installed, vagrant up refuses to start:

Add HashiCorp’s repository with dnf5’s addrepo.

sudo dnf config-manager addrepo --from-repofile=https://rpm.releases.hashicorp.com/fedora/hashicorp.repo

The repo file builds its URL from $releasever, and HashiCorp publishes one tree per Fedora release. Check whether your release has one before you install. This prints 200 when the tree exists and 404 when it doesn’t:

curl -s -o /dev/null -w "%{http_code}\n" https://rpm.releases.hashicorp.com/fedora/$(rpm -E %fedora)/$(uname -m)/stable/repodata/repomd.xml

Fedora 44 returned 200 and Fedora 45 returned 404. On a 404, dnf retries the missing tree four times, prints “Usable URL not found”, skips the repository and carries on. If Fedora’s vagrant is already installed, it then reports Package "vagrant-2.3.4-12.fc45.noarch" is already installed. Nothing in that output says you are still on Fedora’s build. Vagrant ships as a self-contained bundle under /opt/vagrant, so the Fedora 44 build runs on Fedora 45. On Fedora 45 only, point both HashiCorp repositories at the 44 tree, the same workaround our Terraform on Fedora guide uses for the same repository:

sudo dnf config-manager setopt hashicorp.baseurl=https://rpm.releases.hashicorp.com/fedora/44/\$basearch/stable hashicorp-test.baseurl=https://rpm.releases.hashicorp.com/fedora/44/\$basearch/test

dnf5 writes the override to /etc/dnf/repos.override.d/99-config_manager.repo and leaves /etc/yum.repos.d/hashicorp.repo alone. Once the curl check returns 200 for 45, drop the pin with sudo dnf config-manager unsetopt hashicorp.baseurl hashicorp-test.baseurl. Now install Vagrant on either release.

sudo dnf install -y vagrant

dnf imports HashiCorp’s signing key on the first install, and with -y it does so without asking. Compare the fingerprint with the one on HashiCorp’s security page, because that key signs every package you will pull from the repository. The key ID dnf prints, 0xCA026560, is the last eight digits of the fingerprint:

 vagrant x86_64 0:2.4.9-1 hashicorp  180.2 MiB
Importing OpenPGP key 0xCA026560:
 UserID     : "HashiCorp Security (HashiCorp Package Signing) <[email protected]>"
 Fingerprint: D55C0D1AC78A8D8126CB631CFC9CA96ACA026560
The key was successfully imported.
Complete!

If Fedora’s Vagrant is installed, dnf install stops at “already installed” even with a working repo, because the package names match. Run sudo dnf upgrade -y vagrant instead. dnf replaces Fedora’s build with HashiCorp’s and leaves the vagrant-libvirt RPM behind, but HashiCorp’s Vagrant can’t load a plugin installed into the system Ruby, so the libvirt provider vanishes. The last command in this capture shows what happens if you skip the destroy step above: a libvirt guest left in fedora-lab becomes one HashiCorp’s Vagrant cannot manage:

Do not fix that with sudo dnf remove vagrant-libvirt unless you also want KVM gone. On the Fedora 44 VM, removing vagrant and vagrant-libvirt took 259 packages with them, QEMU and libvirt included, because dnf removes the dependencies the plugin pulled in. The plugin section below brings libvirt back on HashiCorp’s build.

Install VirtualBox for Vagrant

Where VirtualBox comes from depends on the release. Oracle’s repository has no Fedora 45 tree, and our VirtualBox testing found that the Fedora 44 build it serves needs a libvpx soname Fedora 45 no longer ships, so on 45 you install RPM Fusion’s akmod build. On 44, Oracle’s repository still works. Our VirtualBox on Fedora guide covers both in depth, including Secure Boot. Our lab VMs ran with Secure Boot off; with it on, the module will not load until you sign it and enroll the key, as that guide shows.

On Fedora 45, enable RPM Fusion free and install VirtualBox with the headers for the running kernel:

sudo dnf -y install https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm
sudo dnf -y install VirtualBox kernel-devel-$(uname -r)

dnf returned after 25 seconds with no kmod-VirtualBox package installed, because akmods compiled the module in the background after the transaction ended. Starting vboxdrv before that build finishes fails, so wait for the kmod package for your kernel, then start the service.

timeout 600 bash -c 'until rpm -q --quiet kmod-VirtualBox-$(uname -r); do sleep 5; done'
sudo systemctl start vboxdrv
lsmod | grep -E "^vbox" | awk '{print $1}'
VBoxManage --version

If the wait hits its 10-minute limit, the akmods build failed, usually because kernel-devel does not match the running kernel; the reason is in /var/cache/akmods/VirtualBox/*.failed.log, and /var/log/akmods/akmods.log records each attempt. A working build loads three modules, and the version carries RPM Fusion’s suffix:

vboxnetadp
vboxnetflt
vboxdrv
7.2.18_RPMFUSIONr175117

On Fedora 44, add Oracle’s repository instead and build the module with Oracle’s setup script, which the RPM install does not run on its own:

sudo curl -fsSL https://download.virtualbox.org/virtualbox/rpm/fedora/virtualbox.repo -o /etc/yum.repos.d/virtualbox.repo
sudo dnf -y install VirtualBox-7.2 kernel-devel-$(uname -r)
sudo /sbin/vboxconfig

The script builds and starts the modules, and VBoxManage --version then reports Oracle’s build (7.2.22r175245 on our Fedora 44 VM):

vboxdrv.sh: Stopping VirtualBox services.
vboxdrv.sh: Starting VirtualBox services.
vboxdrv.sh: Building VirtualBox kernel modules.

Every install path creates a vboxusers group, and only its members can pass USB devices through to guests, so add yourself now rather than after a USB passthrough fails. Group membership is read at login, so log out and back in before you rely on it:

sudo usermod -aG vboxusers $USER

Vagrant does not need the Extension Pack. It drives VirtualBox through VBoxManage, and the guests here used NAT networking and shared folders from the base package, so you can skip the pack and its PUEL license. The VirtualBox guide linked above shows what the pack still adds if you want it.

Run a Vagrant guest on VirtualBox

Vagrant boxes are built per provider, so VirtualBox needs its own copy of the box, and Fedora publishes it next to the libvirt one. Run the same lookup with the VirtualBox file name, then add it under the same name so one Vagrantfile serves both providers:

IMG_URL=https://dl.fedoraproject.org/pub/fedora/linux/releases/44/Cloud/x86_64/images
BOX=$(curl -fsSL ${IMG_URL}/ | grep -oE "Fedora-Cloud-Base-Vagrant-VirtualBox-[^\"]+\.box" | head -1)
SUMS=$(curl -fsSL ${IMG_URL}/ | grep -oE "Fedora-Cloud-[^\"]+-CHECKSUM" | head -1)
SHA=$(curl -fsSL ${IMG_URL}/${SUMS} | awk -v b="($BOX)" '$2==b {print $4}')
vagrant box add --name fedora/44-cloud-base --checksum-type sha256 --checksum "$SHA" ${IMG_URL}/${BOX}
vagrant box list

The list now shows fedora/44-cloud-base twice, once per provider. Give the VirtualBox guest its own project directory with a copy of the same Vagrantfile, because a directory that already holds a machine for one provider refuses vagrant up for another.

mkdir -p ~/vagrant/vbox-lab && cp ~/vagrant/fedora-lab/Vagrantfile ~/vagrant/vbox-lab/ && cd ~/vagrant/vbox-lab

Our first VirtualBox run used the Vagrantfile without the vb.customize line, and it is the failure most worth knowing about. vagrant up printed “Timed out while waiting for the machine to boot” after 5m19s. That is Vagrant’s default 300-second boot timeout plus the box import. The guest was still running, and its console showed the kernel crawling through early boot. Left alone, it reached systemd about 12 minutes in by its own clock and then logged hung-task traces and “Freezing execution” at 986 seconds. Here are the settings VirtualBox had applied from the box:

ostype="Other Linux (64-bit)"
cpus=2
ioapic="off"
paravirtprovider="legacy"
effparavirtprovider="none"

Two CPUs with no I/O APIC and no paravirtualized clock is the combination the VirtualBox manual warns against. With the customize line turning the I/O APIC on and selecting the KVM paravirtualization interface, the same box booted and provisioned in 1m29s on Fedora 45 (with the KVM modules unloaded) and 1m31s on Fedora 44 (with them loaded). Bring the guest up.

vagrant up --provider=virtualbox

VirtualBox guests reach SSH through a forwarded port on 127.0.0.1 rather than a bridge address, and Vagrant moves to the next free port when 2222 is taken:

==> default: Running 'pre-boot' VM customizations...
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 127.0.0.1:2200
    default: SSH username: vagrant
    default: SSH auth method: private key
    default: Key inserted! Disconnecting and reconnecting using new SSH key...
==> default: Machine booted and ready!
==> default: Checking for guest additions in VM...
==> default: Setting hostname...
==> default: Mounting shared folders...
    default: /home/josphat/vagrant/vbox-lab => /vagrant
==> default: Running provisioner: shell...

Check the guest the same way as the libvirt one, and read the VM’s settings back from VirtualBox to confirm the customization applied. Vagrant keeps the VirtualBox UUID in .vagrant/machines/default/virtualbox/id:

vagrant ssh -c "cat /etc/fedora-release; nproc; systemctl is-active nginx; curl -sI localhost | head -1"
VBoxManage showvminfo $(cat .vagrant/machines/default/virtualbox/id) --machinereadable | grep -iE "^(ostype|cpus|memory|ioapic|effparavirtprovider|VMState)="

Our Fedora 44 run, with the versions in use, looked like this.

nproc reporting 2 inside the guest is the quick proof that both vCPUs came up, and effparavirtprovider="kvm" confirms the guest got a paravirtualized clock. If you ever see ioapic="off" on a multi-CPU guest, the Vagrantfile change did not take, and destroying and recreating the machine applies it. If most of your projects use VirtualBox, you can set the default Vagrant provider and drop the --provider flag.

Add libvirt to HashiCorp’s Vagrant

The upstream plugin gives HashiCorp’s Vagrant a libvirt provider again, so one binary drives both hypervisors. vagrant-libvirt’s own documentation strongly recommends the distro package, and its full dependency list also names libguestfs-tools and the tools for rebuilding Vagrant’s bundled libraries. The shorter package set below built the plugin cleanly on both releases. Install libvirt, the compilers and the headers the plugin compiles against, start the sockets, and add yourself to the libvirt group:

sudo dnf -y install @virtualization gcc make libvirt-devel ruby-devel libxml2-devel
for drv in qemu network nodedev nwfilter secret storage interface; do sudo systemctl enable --now virt${drv}d{,-ro,-admin}.socket; done
sudo usermod -aG libvirt $USER
vagrant plugin install vagrant-libvirt

The build took 59 seconds on Fedora 45:

Installing the 'vagrant-libvirt' plugin. This can take a few minutes...
Building native extensions. This could take a while...
Building native extensions. This could take a while...
Installed the plugin 'vagrant-libvirt (0.12.2)'!

The group change matters because the upstream plugin connects to qemu:///system, not Fedora’s session default. Run vagrant up before logging out and back in, and over SSH or on a text console it fails with authentication unavailable: no polkit agent available to authenticate action 'org.libvirt.unix.manage'; on a desktop session you get a polkit password prompt instead. In a fresh session, give this provider its own directory and start the guest:

mkdir -p ~/vagrant/libvirt-lab && cp ~/vagrant/fedora-lab/Vagrantfile ~/vagrant/libvirt-lab/ && cd ~/vagrant/libvirt-lab
vagrant up --provider=libvirt
sudo virsh list

The guest came up in 54 seconds on Fedora 45 and 1m07s on Fedora 44, and root’s libvirt sees it:

 Id   Name                  State
-------------------------------------
 1    libvirt-lab_default   running

The disk goes to /var/lib/libvirt/images, the guest lands on the plugin’s own 192.168.121.0/24 management network, and sudo virsh list shows it, which is what you want if other tools such as virt-manager should see your Vagrant guests.

Every command after that prints [fog][WARNING] Unrecognized arguments: libvirt_ip_command. It comes from the fog-libvirt library the plugin uses and did not affect anything we ran, so you can treat it as noise. Fedora’s KVM and virt-manager setup covers the libvirt side in more depth, including the default network.

Run VirtualBox and KVM on the same host

Both providers can be installed on one host, but run one hypervisor’s guests at a time. Since VirtualBox 7.2.2, VirtualBox uses the kernel’s KVM interfaces to take and release VT-x on kernel 6.16 and newer, so it no longer fails just because kvm_intel is loaded. On Fedora 44, with KVM loaded at boot, VirtualBox guests started normally, and lsmod showed kvm_intel held by two references while a VirtualBox guest ran.

Running guests from both at once is where it broke. With a VirtualBox guest up on Fedora 44, starting a KVM guest ended at once with KVM: entry failed, hardware error 0x0, and the kernel logged kvm_intel: vmread failed. On Fedora 45 we tried the other order: with kvm_intel unloaded and a VirtualBox guest running, sudo modprobe kvm_intel failed with Input/output error, and dmesg recorded kvm: enabling virtualization on CPU0 failed. Our lab hosts were themselves VMs with nested virtualization, so a bare-metal machine may fare better, but we wouldn’t count on it. Run vagrant halt on one provider’s guests before you start the other’s, and leave the KVM modules loaded.

Manage and clean up Vagrant machines

Every machine Vagrant knows about, across all project directories and providers, shows up in one place:

vagrant global-status

The list is a cache, so a machine you deleted outside Vagrant can linger in it until you run vagrant global-status --prune. You can act on any entry from any directory by its ID, for example vagrant halt 86c33d8, which saves a cd when you only want to stop something. With the fedora-lab guest destroyed, our Fedora 45 host listed one guest per provider:

id       name    provider   state    directory
-------------------------------------------------------------------------
86c33d8  default virtualbox poweroff /home/josphat/vagrant/vbox-lab
0b0bdc2  default libvirt    running  /home/josphat/vagrant/libvirt-lab

From inside a project directory, these are the day-to-day commands:

• vagrant halt shuts the guest down and keeps its disk
• vagrant provision re-runs the provisioner on a running guest
• vagrant destroy -f deletes the guest and its disk
• vagrant box remove fedora/44-cloud-base --provider libvirt deletes one provider’s copy of a box, and asks first only when a machine still uses it

Removing a libvirt box does not free all of its space. vagrant-libvirt uploads every box into the storage pool as a volume, and box remove only deletes the copy in ~/.vagrant.d. It says so, in a message that’s easy to scroll past:

Vagrant-libvirt plugin removed box only from /home/josphat/.vagrant.d/boxes directory
From Libvirt storage pool you have to delete image manually(virsh, virt-manager or by any other tool)

List the pool to find the box volume. The upstream plugin uses the system pool, which needs sudo virsh; for boxes added by Fedora’s Vagrant, run the same commands as virsh -c qemu:///session without sudo:

sudo virsh vol-list default | grep VAGRANTSLASH

The name encodes the box name, its version and a timestamp, so yours will differ:

 fedora-VAGRANTSLASH-44-cloud-base_vagrant_box_image_0_1792983844_box.img   /var/lib/libvirt/images/fedora-VAGRANTSLASH-44-cloud-base_vagrant_box_image_0_1792983844_box.img

Delete it by that name. A guest created from the box still uses the volume as its backing file, so destroy those guests first:

sudo virsh vol-delete fedora-VAGRANTSLASH-44-cloud-base_vagrant_box_image_0_1792983844_box.img --pool default

virsh confirms with Vol ... deleted, and the space is back. For provisioning beyond a shell script, the Ansible provisioner guide picks up from the Vagrantfile used here. On a fresh Fedora workstation we’d take HashiCorp’s Vagrant with the libvirt plugin, plus VirtualBox from whichever source the release supports. Keep the I/O APIC line in every multi-CPU VirtualBox definition, and use Fedora’s own vagrant-libvirt package on hosts that only ever run KVM.