Eli Taft

Eli Taft

Debian, VirtualBox, & Vagrant

Debian Virtualbox Vagrant

This post applies to you if:

  • You use Debian Buster (10)

  • You want to use the most recent version of VirtualBox available to Debian Buster, which is VirtualBox 6.1

  • You want to use vagrant to provision VirtualBox VMs, and so you install the most recent version of vagrant available to Debian Buster, which is vagrant 2.2.3+dfsg-1

  • You type “vagrant up” and encounter the following:

    $ vagrant up Bringing machine ‘default’ up with ‘libvirt’ provider…

    Error while connecting to libvirt: Error making a connection to libvirt URI qemu:///system?no_verify=1&keyfile=/home/elimtaft/.ssh/id_rsa: Call to virConnectOpen failed: Failed to connect socket to ‘/var/run/libvirt/libvirt-sock’: No such file or directory

Maybe you then Googled this answer, and someone recommended specifying VirtualBox as the vagrant provider explicitly. Then you may have encountered this error:

$ vagrant up –provider virtualbox

The provider ‘virtualbox’ that was requested to back the machine ‘default’ is reporting that it isn’t usable on this system. The reason is shown below:
Vagrant has detected that you have a version of VirtualBox installed that is not supported by this version of Vagrant. Please install one of the supported versions listed below to use Vagrant:
4.0, 4.1, 4.2, 4.3, 5.0, 5.1, 5.2, 6.0
A Vagrant update may also be available that adds support for the version you specified. Please check www.vagrantup.com/downloads.html to download the latest version.

HERE IS WHAT IS GOING ON

The vagrant package, for whatever reason, hasn’t been updated to support VirtualBox 6.1. There appears to be no good reason why it’s not. The good news is that this is really easy to solve, as outlined by Paul Neumann at https://github.com/oracle/vagrant-projects/issues/178:

Modify the file /usr/share/rubygems-integration/all/gems/vagrant-2.2.3/plugins/providers/virtualbox/plugin.rb and add a line at the end of the Driver module for VirtualBox 6.1:

module Driver
  autoload :Meta, File.expand_path("../driver/meta", __FILE__)
  autoload :Version_4_0, File.expand_path("../driver/version_4_0", __FILE__)
  autoload :Version_4_1, File.expand_path("../driver/version_4_1", __FILE__)
  autoload :Version_4_2, File.expand_path("../driver/version_4_2", __FILE__)
  autoload :Version_4_3, File.expand_path("../driver/version_4_3", __FILE__)
  autoload :Version_5_0, File.expand_path("../driver/version_5_0", __FILE__)
  autoload :Version_5_1, File.expand_path("../driver/version_5_1", __FILE__)
  autoload :Version_5_2, File.expand_path("../driver/version_5_2", __FILE__)
  autoload :Version_6_0, File.expand_path("../driver/version_6_0", __FILE__)
  autoload :Version_6_1, File.expand_path("../driver/version_6_1", __FILE__)
end

Modify the “driver_map” section in the file /usr/share/rubygems-integration/all/gems/vagrant-2.2.3/plugins/providers/virtualbox/driver/meta.rb to add VirtualBox 6.1:

driver_map   = {
  "4.0" => Version_4_0,
  "4.1" => Version_4_1,
  "4.2" => Version_4_2,
  "4.3" => Version_4_3,
  "5.0" => Version_5_0,
  "5.1" => Version_5_1,
  "5.2" => Version_5_2,
  "6.0" => Version_6_0,
  "6.1" => Version_6_1,
}

Create the file /usr/share/rubygems-integration/all/gems/vagrant-2.2.3/plugins/providers/virtualbox/driver/version_6_1.rb and put the following in it:

require File.expand_path("../version_6_0", __FILE__)

module VagrantPlugins
  module ProviderVirtualBox
    module Driver
      # Driver for VirtualBox 6.1.x
      class Version_6_1 < Version_6_0
        def initialize(uuid)
          super

          @logger = Log4r::Logger.new("vagrant::provider::virtualbox_6_1")
        end
      end
    end
  end
end

You should be all set! Try typing ‘vagrant up’ again and see if it works.

Buy why are you still using VirtualBox, you ask? Why not just use docker? Well, for most cases, I find docker adequate for local development and testing. But sometimes you may need to have a local VM that actually functions more like a server, and not just like a simple containerized service. Case in point — one of my current clients has tasked me with creating a custom front-end management interface for their servers. They want to be able to check things like who is logged in, how much disk space is in use, what the RAM is doing, whether daily backups are running successfully, etc. In order to test this management interface locally, I want to have a test server that is preferably on my machine. VirtualBox is much more able to create this kind of environment than docker. That is all!

← Back to home