Installing and running Vagrant using qemu-kvm

Vagrant is a brilliant tool, used by DevOps professionals, coders, sysadmins and regular geeks to stand up repeatable infrastructure for development and testing. From their website:

Vagrant is a tool for building and managing virtual machine environments in a single workflow. With an easy-to-use workflow and focus on automation, Vagrant lowers development environment setup time, increases production parity, and makes the “works on my machine” excuse a relic of the past.

If you are already familiar with the basics of Vagrant, the documentation provides a better reference build for all available features and internals.

Vagrant provides easy to configure, reproducible, and portable work environments built on top of industry-standard technology and controlled by a single consistent workflow to help maximize the productivity and flexibility of you and your team.

https://www.vagrantup.com/intro

This guide will walk through the steps necessary to get Vagrant working on a Fedora-based machine.

I started with a minimal install of Fedora Server as this reduces the memory footprint of the host OS, but if you already have a working Fedora machine, either Server or Workstation, then this should still work.

Check the machine supports virtualisation:

$ sudo lscpu | grep Virtualization Virtualization:                  VT-x Virtualization type:             full

Install qemu-kvm:

sudo dnf install qemu-kvm libvirt libguestfs-tools virt-install rsync

Enable and start the libvirt daemon:

sudo systemctl enable --now libvirtd

Install Vagrant:

sudo dnf install vagrant

Install the Vagrant libvirtd plugin:

sudo vagrant plugin install vagrant-libvirt

Add a box

vagrant box add fedora/32-cloud-base --provider=libvirt

Create a minimal Vagrantfile to test

$ mkdir vagrant-test $ cd vagrant-test $ vi Vagrantfile

Vagrant.configure("2") do |config| config.vm.box = "fedora/32-cloud-base" end

Note the capitalisation of the file name and in the file itself.

Check the file:

vagrant status

Current machine states: default not created (libvirt) The Libvirt domain is not created. Run 'vagrant up' to create it.

Start the box:

vagrant up

Connect to your new machine:

vagrant ssh

Thatโ€™s it – you now have Vagrant working on your Fedora machine.

To stop the machine, use vagrant halt. This simply halts the machine but leaves the VM and disk in place.
To shut it down and delete it use vagrant destroy. This will remove the whole machine and any changes you’ve made in it.

Next steps

You don’t need to download boxes before issuing the vagrant up command – you can specify the box and the provider in the Vagrantfile directly and Vagrant will download it if it’s not already there. Below is an example which also sets the amount memory and number of CPUs:

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure("2") do |config|
  config.vm.box = "fedora/32-cloud-base"
  config.vm.provider :libvirt do |libvirt|
    libvirt.cpus = 1
    libvirt.memory = 1024
  end
end

For more information on using Vagrant, creating your own machines and using different boxes, see the official documentation at https://www.vagrantup.com/docs

There is a huge repository of boxes ready to download and use, and the official location for these is Vagrant Cloud – https://app.vagrantup.com/boxes/search. Some are basic operating systems and some offer complete functionality such as databases, web servers etc.

FAQs and Guides Fedora Contributor Community Fedora Project community For Developers For System Administrators Using Software

21 Comments

  1. Lucas

    Very useful. I will test with qemu-kvm. I’ve had problems with vagrant and vbox, so I stopped using it.

  2. Sergey

    I understand the use of Vagrant for Virtual Box, etc., but why use it for KVM ?
    We have a virsh and ansible.

    • As with anything Unix/Linux there are many ways to get the job done!

      While virsh commands and Ansible would also work, the simplicity of finding a suitable Vagrant box and getting it up and running quickly reduces the learning curve for anyone new to automated provisioning as it takes away a number of the steps required. I believe this makes it a fantastic tool for quickly creating machines for testing or other lab work.

    • Sandra

      With KVM you would have to set up all the networking and partitioning and so on you self, and Vagrant have to handy builtin commands, which should make many taskes easier.

      There would however be 2 good reasons to go with KVM over Vagrant:

      you can use snapshots with KVM, so you can make a snapshot between each of your virsh commands and that way simulate the layers in Docker/Podman that speeds up building the box/image. Vagrant can’t do this for some strange reason.
      All commands in a Vagrant file are executed as an non-privileged user, so you can’t copy a file directly to e.g. /etc. You first have to copy the file to /tmp and then write a script that copies the file from /tmp to /etc and then execute it. With virsh that is a one-liner.

  3. Serge Meeuwsen

    Hi,
    Thanks for providing this write up! This works fine with Linux based boxes but unfortunately it seems to be broken for Windows based boxes.
    I have tried several and always get the “kernel_require.rb:83:in `require’: cannot load such file — winrm (LoadError)” error.
    According to the hashicorp site you need to install vagrant 2.2.10 but then I had problems installing the vagrant-libvirt plugin… It is probably a dependency issue but I couldn’t figure it out.

  4. Mehdi

    Thank you for the article. Didn’t get a chance to work with Vagrant before. Seems like some Docker projects can be done with Vagrant.

    Btw, does Vagrant anything to do with Gnome Boxes?

    • MattPie

      @Mehdi,

      Vagrant doesn’t really have much to do with Gnome Boxes, other than Gnome Boxes manages KVM VMs so you may be able to see the VMs Vagrant spins up in there.

      And FWIW, Fedora (32, at least) comes with podman install, which is CLI-compatible with docker so many of the same commands will work. Like:
      piechota@localhost Downloads]$ podman run -it ubuntu bash

      Trying to pull docker.io/library/ubuntu…
      Getting image source signatures
      Copying blob 990916bd23bb done
      Copying blob 534a5505201d done
      Copying blob e6ca3592b144 done
      Copying config bb0eaf4eee done
      Writing manifest to image destination
      Storing signatures
      root@223636bf41b2:/# more /etc/lsb-release
      DISTRIB_ID=Ubuntu
      DISTRIB_RELEASE=20.04
      DISTRIB_CODENAME=focal
      DISTRIB_DESCRIPTION=”Ubuntu 20.04.1 LTS”
      root@223636bf41b2:/# exit
      exit

  5. Sandra

    Why do you install vagrant-libvirt from Vagrant and not

    dnf -y install vagrant-libvirt

    ?

  6. Why not to mention the developer guide from Fedora Developer [0]? You would also see that we have vagrant-libvirt directly packaged in Fedora.

    [0] https://developer.fedoraproject.org/tools/vagrant/vagrant-libvirt.html

  7. Sandra

    Ok, so it makes a lot of sense for Windows boxes. So why still do it, when the box is Fedora/Linux?

    • Eric L.

      I also don’t install

      vagrant-libvirt

      because I know that I need more Vagrant plugins than are packaged as RPM, and, if you dare mixing up RPM-packaged and “native” Vagrant-plugins, it always go wrong at some point in time. I even block all vagrant plugins to avoid any issue with Ruby dependencies:

      $ cat /etc/dnf/dnf.conf
      [main]
      excludepkgs=vagrant-*

      It still goes wrong from time to time when the Vagrant-RPM is upgraded, but then you follow all the recommendations from the Vagrant-CLI (clean-up/rebuild/update the plug-ins) and it fixes the issue.

      To be honest, I’d like to get rid of Vagrant and replace it fully with Ansible. It’s technically possible but, as someone else wrote, the Vagrant library of prepared images is just too comfortable.

  8. Jeff Pettorino

    So this does not work with Fedora 33 beta, nor Fedora 32. I tried both, a couple of times.
    The problem comes from an old and well established bug:
    https://bugzilla.redhat.com/show_bug.cgi?id=1835308

    So what did you do to overcome this, and can you update the article to include the steps?

    I’ve tried both the vagrant plugin installer and the RPM package vagrant-libvirtd. Same problems with racc-1.5.0 in both cases.

    • Hi Jeff

      I just built a new F32 VM to test this on, and everything worked as expected. This is a vanilla build using Fedora 32 Server. No updates installed, just right out of the box. The only thing I did in the OS install was add my user account to the wheel group so I could use sudo.

      $ libvirtd –version
      libvirtd (libvirt) 6.1.0

      $ vagrant –version
      Vagrant 2.2.9

      $ sudo vagrant plugin install vagrant-libvirt
      Installing the ‘vagrant-libvirt’ plugin. This can take a few minutes…
      Installed the plugin ‘vagrant-libvirt (0.0.45)’!

      I copied and pasted commands from this article and saw no errors. Sorry I can’t offer more advice, but the steps above do work.

      • Jeff Pettorino

        Hi Andy, I double checked and found an error, I was deploying F33-Beta for all of my tests. I can confirm as well that on a (properly) installed F32 the article instructions work fine.
        Thanks for being patient. ๐Ÿ™‚

        • Hi Jeff

          Glad you got it sorted! ๐Ÿ™‚
          I’m always happy to help if people have questions about my articles, so no worries about asking.

    • I have Fedora 32 and Vagrant installed as vagrant-libvirt RPM package. I don’t use any non packaged plugins, perhaps this is why it works for me?

    • Tom Christopher

      The only way I found around this is to install toolbox on the system. Then run toolbox create -c libvirt -r f29 to create a Fedora 29 container. Then I run the installation as documented on the vagrant-libvirt github page. I also run terraform-libvirt from this same container.

Comments are Closed

The opinions expressed on this website are those of each author, not of the author's employer or of Red Hat. Fedora Magazine aspires to publish all content under a Creative Commons license but may not be able to do so in all cases. You are responsible for ensuring that you have the necessary permission to reuse any work on this site. The Fedora logo is a trademark of Red Hat, Inc. Terms and Conditions