Fedora Cloud Vagrant Boxes in Atlas

Since the release of Fedora 22, Fedora began creating Vagrant boxes for cloud images in order to make it easier to set up a local environment for development or testing. In the Fedora 22 release cycle we worked out quite a few kinks and we are again releasing libvirt and virtualbox Vagrant boxes for Fedora 23.

Additionally, for Fedora 23, we are making it easier for the users to grab these boxes by having them indexed in Hashicorp’s Atlas. Atlas is essentially an index of Vagrant boxes that makes it easy to distribute them (think of it like a Docker registry for virtual machine images). By indexing the Fedora boxes in Atlas, users now have the option of using the


software to download and add the boxes automatically, rather than the user having to go grab the boxes directly from the mirrors first (although this is still an option).

In order to get started with the Fedora cloud base image, run the following command:

# vagrant init fedora/23-cloud-base && vagrant up

Alternatively, to get started with Fedora Atomic host, run this command:

# vagrant init fedora/23-atomic-host && vagrant up

The above commands will grab the latest indexed images in Atlas and start a virtual machine without the user having to go download the image first. This will make it easier for Fedora users to develop and test on Fedora! If you haven’t delved into Vagrant yet then you can get started by visiting the Vagrant page on the Fedora Developer Portal. Let us know on the Fedora Cloud mailing list if you have any trouble.

Fedora Contributor Community For Developers For System Administrators


  1. Robert Smol

    Ok guys, good start, but:

    virtuabox provider is missing VirtualBox additions, so no synced folders. Fix this 3rd party means repackaging since CDROM is not added to this box.

    libvirt provider, even when I install vagrant-libvirt plugin and have 9p module loaded, no shared folders are working, defaulting to rsync….

    Please finish the integration. https://atlas.hashicorp.com/fedora/

    • Hey Robert,

      Thanks for the feedback. Unfortunately I don’t think we can package the guest additions in Fedora because of licensing. You have a couple of options here: you can either mount the CDROM iso file in the running VM and install from there or you could possibly use the guest additions from rpmfusion: ftp://rpmfind.net/linux/rpmfusion/free/fedora/updates/testing/23/x86_64/

      On our end we can add a CDROM device to the boxes in the future so that user’s can insert disks if they like. I opened a ticket for this: https://fedorahosted.org/cloud/ticket/136

      As for 9p, yes it defaults to rsync because 9p can be difficult to work with. For me, if I want to use 9p, then I add a line like this to my Vagrantfile:

      config.vm.synced_folder "/guests/sharedfolder", "/sharedfolder", type: "9p", :accessmode => "mapped"

      . Can you try that and see if it works for you?

      • Robert Smol

        Hi Dusty,

        Thanks for helping me out, I am no Linux sysadmin expert and I’ve tried:

        sudo su -c 'dnf install http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm'
        sudo dnf install -y VirtualBox-guest kmod-VirtualBox

        This installed bunch of stuff (like support for X11), but after restart it still says GuestAdditions not installed/working. I’ve checked the status of the service:

        [root@localhost ~]# systemctl status vboxservice.service
        ● vboxservice.service - VirtualBox guest services
           Loaded: loaded (/usr/lib/systemd/system/vboxservice.service; enabled; vendor preset: disabled)
           Active: failed (Result: exit-code) since Mon 2015-11-09 08:43:25 UTC; 1s ago
          Process: 1692 ExecStart=/usr/bin/VBoxService -f (code=exited, status=1/FAILURE)
         Main PID: 1692 (code=exited, status=1/FAILURE)

        Nov 09 08:43:25 localhost.localdomain systemd[1]: Started VirtualBox guest services.
        Nov 09 08:43:25 localhost.localdomain systemd[1]: Starting VirtualBox guest services...
        Nov 09 08:43:25 localhost.localdomain VBoxService[1692]: VBoxService: error: VbglR3Init failed with rc=VERR_FILE_NOT_FOUND
        Nov 09 08:43:25 localhost.localdomain systemd[1]: vboxservice.service: Main process exited, code=exited, status=1/FAILURE
        Nov 09 08:43:25 localhost.localdomain systemd[1]: vboxservice.service: Unit entered failed state.
        Nov 09 08:43:25 localhost.localdomain systemd[1]: vboxservice.service: Failed with result 'exit-code'.

        So no luck for me yet.

        As for 9p, your solution works well. I just had to add it to custom provider block:

        config.vm.provider "libvirt" do |lv, override|
              override.vm.synced_folder './', '/vagrant', type: '9p', disabled: false, accessmode: "mapped"

        I have to provide one Vagrant file for VirtualBox and for libvirt – my friends are developing on mac, I am on linux.

        If you cannot put this directly into the boxes, it would be really nice if a small text about setting stuff up was present in the box information (at least link to this new developer portal).

        Another hint from me:

        Vagrant with VirtualBox sometimes running CPU 100% for no reason, the solution seems to be to add “SERIAL = false” straight into the Vagrant file. Another issue was with files were updated, but webserver was still sending old content (although if you cat the file inside the box you get new content). This can be mitigated by setting ‘sendfile off’ (for nginx, for others check doc).

        • Robert Smol

          OK, further regarding VirtualBox, I’ve manged to find the bug:

          [vagrant@localhost ~]$ cat /usr/lib/udev/rules.d/60-vboxguest.rules
          ACTION=="add", KERNEL=="vboxguest", SUBSYSTEM=="misc", OWNER="root", MODE="0600"
          ACTION=="add", KERNEL=="vboxuser", SUBSYSTEM=="misc", OWNER="root", MODE="0666"
          [vagrant@localhost ~]$ sudo modprobe vboxuser
          modprobe: FATAL: Module vboxuser not found.

          After removing the second line, VirtualBox additions starts fine. However the Vagrant will keep rsyninc. It stores some metadata .vagrant/boxes/default/libvirt. Vagrant says you have to repackage the box.

          To me it looks like not being able to install the VirtualBox Additions is a huge bummer as I really did not found a way to fix this without repackaging (which sucks).

        • Vladimir

          Robert, just install vagrant-vbguest plugin, and add following to your Vagrantfile:

          config.vbguest.auto_update = true
          config.vbguest.auto_reboot = true
          config.vbguest.installer = VagrantVbguest::Installers::RedHat

          Fedora 23 Basebox will start working since 4.3.32 version (worked on my OSX machine and linux server)
          Fedora 22 Basebox working fine since 4.3.12 (latest stable build with all features for Windows hosts)

          Works like a charm, Fedora is still the best!

          • Vladimir, thanks for the tip. This looks like it could possibly get us what we want. Robert, can you try the vagrant-vbguest plugin and see if that gives you a working setup?

            • Vladimir

              Do not hesitate to ask 🙂 Will glad to help with it. I completely reworked vagrant for myself and my colleagues, because I think it using wrong way by most of developers 🙂

              For example instead of basebox versioning it better to use versionning of provision (as a set of small bricks), over one minimal basebox (thanks Dusty, I got one almost perfect with Fedora23). And much more other stuff. It really great tool, even, I think, HashiCorp does not know how great this tool is, if go inside and little bit customize it 🙂

            • Robert Smol

              some partial success with the box, it installs the stuff, but it keeps rsyncing, even after reboot. I am on fresh fedora 23 (with virtualbox installed from rpmfusion):

              Downloading VirtualBox Guest Additions ISO from http://download.virtualbox.org/virtualbox/5.0.8/VBoxGuestAdditions_5.0.8.iso
              Copy iso file /home/rsmol/.vagrant.d/tmp/VBoxGuestAdditions_5.0.8.iso into the box /tmp/VBoxGuestAdditions.iso
              mount: /dev/loop0 is write-protected, mounting read-only
              Installing Virtualbox Guest Additions 5.0.8 - guest version is unknown
              Verifying archive integrity... All good.
              Uncompressing VirtualBox 5.0.8 Guest Additions for Linux............
              VirtualBox Guest Additions installer
              Copying additional installer modules ...
              Installing additional modules ...
              Removing existing VirtualBox non-DKMS kernel modules[  OK  ]
              Building the VirtualBox Guest Additions kernel modules
              Building the main Guest Additions module[  OK  ]
              Building the shared folder support module[  OK  ]
              Building the OpenGL support module[  OK  ]
              Doing non-kernel setup of the Guest Additions[  OK  ]
              Starting the VirtualBox Guest Additions [  OK  ]
              Installing the Window System drivers
              Could not find the X.Org or XFree86 Window System, skipping.
              An error occurred during installation of VirtualBox Guest Additions 5.0.8. Some functionality may not work as intended.
              In most cases it is OK that the "Window System drivers" installation failed.
              Cleaning up downloaded VirtualBox Guest Additions ISO...
              ==> default: Checking for guest additions in VM...
              ==> default: Rsyncing folder: /home/rsmol/Code/CTP/camera-api/ => /vagrant

              And even after reboot:

              ==> default: Machine booted and ready!
              GuestAdditions 5.0.8 running --- OK.
              ==> default: Checking for guest additions in VM...
              ==> default: Rsyncing folder: /home/rsmol/Code/CTP/camera-api/ => /vagrant
              ==> default: Machine booted and ready!
              GuestAdditions 5.0.8 running --- OK.
              ==> default: Checking for guest additions in VM...
              ==> default: Rsyncing folder: /home/rsmol/Code/CTP/camera-api/ => /vagrant

              This is my Vagrant:

              config.vm.provider "virtualbox" do |vb, override|
                  override.vbguest.auto_update = true
                  override.vbguest.auto_reboot = true
                  override.vbguest.installer = VagrantVbguest::Installers::RedHat
              • You just need to override what was provided as the default. Something like this might work:

                config.vm.synced_folder ".", "/vagrant", type: "virtualbox"
              • Vladimir

                This part is also very often broken in fresh VirtualBoxes. Try 4.3.32 or even 4.3.20 version if overriding from Dusty doesn’t work. I completely switched off vboxfs synced folders in my virtual machines, because of vboxfs stability issue, and using nfs. Rsync is pretty enough for provision.

                Stability of new VB versions is a known issue. For example for the Windows hosts is a still 4.3.12 is the latest stable version (all features is working as should). So starting to think about switching to KVM libvrt virtualization for example is a good idea.

                According New VB version 5. They have a new option – virtualization adapter type (kvm/libvrt/legacy…) With wrong type it will work slower. On my yocto farm it slower in 2 times with default virtualization adapter.

  2. Good work Fedora team!

  3. Vladimir

    Dusty, I does not know exactly where is a right place to discuss your vagrant boxes. Could you please show me how to increase your 40G limit for dynamic disk ? Should I install parted, increase limit, then uninstall and repackage the box? In Vagrant documentation the suggest to use unlimited dynamic sized disks (=2 TB). What the reason to limit it to 40G? It costs nothing in gazebos size, but could be very helpful. I really want to switch to your baseboxes (they are ideal). But this limit makes them useless for yocto projects (Linux embedded related stuff).

    • Vladimir,

      This makes sense, and it’s something we could do relatively easily.

      Right now we control the disk setup for this build in two ways.

      1) We can pass a virtual disk size to the build system. The Anaconda installer will be presented with a blank disk of this size when it runs. This is currently set at 40 GB, for no reason other than it was suggested as a reasonably large size for dynamic disks, but not so large that people can easily get into trouble.

      2) The kickstart file used to actually generate the image can be set to grow (or limit) how big things get. At present, the kickstart for the Vagrant boxes inherits from the kickstart used to generate cloud images. For Vagrant we layer in a few changes (adding the insecure key, setting up sudo).

      Cloud base kickstart file: https://git.fedorahosted.org/cgit/spin-kickstarts.git/tree/fedora-cloud-base.ks
      Vagrant kickstart overlay: https://git.fedorahosted.org/cgit/spin-kickstarts.git/tree/fedora-cloud-base-vagrant.ks

      So, I guess the open question for me is whether we should look at blowing up the virtual disk size and letting Anaconda fill it all right away (resulting in a single ~2 TB root filesystem) or whether we should use the large virtual disk, but leave it as an exercise to the user to either expand the root filesystem, or use the extra virtual space for something else.


      • Vladimir

        Hi imcleod,

        Is this kickstart scripts are you using to generate your baseboxes? Thanks a lot for this. I do not believe in Packer from Hashicorp to generate baseboxes, it repeats the same design problems. So, this ks is realy game changer for my case. Hope, I can use it in my workflow.

        According 40G/2TB your decision now looks clear for me. It has no straightforward solution, but how about to generate 2 baseboxes? 40G and 2Tb version. Not so beautiful solution, but on Atlas servers they have a lot of boxes with fedora, 2 more boxes does not change something.

        Another solution looks more beautiful – create additional “unlimited size” disk and mount it to somewhere appropriate (home or opt) that everybody could do in their custom Vagrantfile (https://gist.github.com/leifg/4713995). There should be one shell provision with mounting before main provision set. But it is not a big problem, I think. It will be little bit longer, than just obtain box from you, guys.

  4. Gunnar

    Hi, thanks for making this available.

    I set up a box as described above which works nicely and I can SSH into it via “vagrant ssh” (I am using VirtualBox on OS X) . But when I try to update/install packages with dnf (e.g. by running “sudo dnf install htop”), the box crashes before it even gets to download anything. In the VirtualBox manager the VM is in state “Aborted” afterwards. When SSH-ing into it again, I cannot seem to find any error logs. Any idea what might be wrong?

  5. JayF

    In case you’re like me, and you tried to use this box and got an error about “biosdevname” not existing (not installed on this box), upgrading Vagrant fixed that issue for me. Just leaving this here for future folks who have the same problem.

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