Vagrant: Support Virtualbox 6.1

Created on 11 Dec 2019  路  21Comments  路  Source: hashicorp/vagrant

Virtualbox 6.1 was released December 10 and it appears Vagrant does not support this version.

enhancement providevirtualbox task-small

Most helpful comment

I patched Vagrant on macOS with this script:

curl https://github.com/briancain/vagrant/commit/fb4e6985e142da56bad143d70600cd3695c91757.patch > /tmp/vagrant_226_virtualbox_610.patch
cd /opt/vagrant/embedded/gems/2.2.6/gems/vagrant-2.2.6
sudo git apply --verbose --exclude='website/*' /tmp/vagrant_226_virtualbox_610.patch

All 21 comments

Vagrant v2.2.6:

...

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

...

Workaround available here: https://github.com/oracle/vagrant-boxes/issues/178#issue-536720633

I would suggest to possibly introduce something that covers from 6.0 and over.
So, something like ">6.0"; VBox CLI usually does not change on functions used by Vagrant and, in the worst case, having ">6.0" could only introduce a different type of issue when future VirtualBox releases will be available.
BTW, a complete workaround is available at: https://blogs.oracle.com/scoter/getting-vagrant-226-working-with-virtualbox-61-ga

Wildcarding a whole major version of VB may be risky, the API can change enough to break Vagrant in that time. Glad to see the workaround listed here, thank you for that. I've ended up in a bit of a cascade - I need Linux 5.4 for my machine, Virtualbox 6.1 is the only version that supports that kernel, and then Vagrant doesn't support that.

I've got the Vagrant source code on my laptop from some other patching work - what kind of testing needs to be done to certify Vagrant for VB6.1? I'm happy to help out.

I agree with you Greg but managing release by release could take us on this situation where, for each major release, we'll have the issue (this kind of thing already happened for 6.0).
At the end, the worst case while introducing a wildcard could be to get Vagrant failing while trying to leverage VirtualBox provider (as it already happens today).
I'm going to talk with VBox engineers to possibly get VirtualBox QA/QE processes including Vagrant but, at the same time, I do not see as a bad idea the "wildcard" option.
BTW, there's no particular required test for VirtualBox 6.1; CLI features you're leveraging are the same we had for 6.0 and even 5.x releases.

Well, that's what Virtualbox betas and release candidates are for ;-)

For reference, 6.1 appears to be working just fine with Vagrant 2.2.6 on my Kubuntu 19.10/Kernel 5.4 laptop.

You're right Greg but no-one (that I'm aware) of us reported the issue to the Hashicorp/Vagrant team.
It seems that no-one in Hashicorp tested Beta/RC releases but, again, someone of us should report the issue earlier.
@briancain any comment ?

Hey all!

First, thanks so much for bringing this issue and new VirtualBox release to our attention.

We have considered being looser as to which VirtualBox versions we support, but ideally we would rather have folks on an older version of VirtualBox and see this unsupported message temporarily rather than run into frustrating or unusual errors from a cutting edge release. By doing this, it gives us at least a bit of time to make sure the most basic operations between VirtualBox and Vagrant work before pushing out a release that supports the new version. This isn't the most ideal solution for users who like being on the cutting edge, but generally we believe a warning is a better user experience than an unexpected exception.

For now, you all are free to run Vagrant from source if you really wish to be on the cutting edge of what Vagrant supports with VirtualBox. But as far as what we are supporting in Vagrant inside an official package, we might be a few weeks behind releasing support for VirtualBox 6.1. Sorry about that!
Again, we really appreciate you all letting us know so quickly, so thanks again! :heart:

@briancain target of my comment was a sort of proposal to anticipate this kind of issue.
VirtualBox 6.1 BETA-1 had been announced ~Sept. 2019......and GA release Dec. 11th; during this time we could think to work together (I'm PM for Linux and Virtualization at Oracle) to possibly avoid this kind of problem for the VirtualBox GA release. Thoughts ?

For Arch Linux users, if they want to rebuild the vagrant package with the patch:

$ svn diff
Index: PKGBUILD
===================================================================
--- PKGBUILD    (revision 537505)
+++ PKGBUILD    (working copy)
@@ -10,7 +10,7 @@

 pkgname=vagrant
 pkgver=2.2.6
-pkgrel=1
+pkgrel=2
 pkgdesc="Build and distribute virtualized development environments"
 arch=('x86_64')
 url="https://vagrantup.com"
@@ -22,10 +22,17 @@
 conflicts=('vagrant-substrate')
 replaces=('vagrant-substrate')
 source=($pkgname-$pkgver.tar.gz::https://github.com/mitchellh/$pkgname/archive/v$pkgver.tar.gz
-        "git+https://github.com/mitchellh/vagrant-installers.git#commit=7b7fb86")
+        "git+https://github.com/mitchellh/vagrant-installers.git#commit=7b7fb86"
+        "package.patch")
 md5sums=('19d7b591503ab2190d5720dc5a64023c'
-         'SKIP')
+         'SKIP'
+         '04c2197786d7c9de598683cf28e79bf4')

+prepare() {
+    cd $pkgname-$pkgver
+    patch --forward --strip=2 --input="${srcdir}/package.patch"
+}
+
 build() {
   cd $pkgname-$pkgver
 ```

And the `package.patch` file:
```diff
diff --unified --recursive --text --new-file package.orig/vagrant-2.2.6/plugins/providers/virtualbox/driver/meta.rb package.new/vagrant-2.2.6/plugins/providers/virtualbox/driver/meta.rb
--- package.orig/vagrant-2.2.6/plugins/providers/virtualbox/driver/meta.rb  2019-12-13 10:37:24.272748431 +0100
+++ package.new/vagrant-2.2.6/plugins/providers/virtualbox/driver/meta.rb   2019-12-13 10:39:14.819687439 +0100
@@ -64,6 +64,7 @@
             "5.1" => Version_5_1,
             "5.2" => Version_5_2,
             "6.0" => Version_6_0,
+            "6.1" => Version_6_1,
           }

           if @@version.start_with?("4.2.14")
diff --unified --recursive --text --new-file package.orig/vagrant-2.2.6/plugins/providers/virtualbox/driver/version_6_1.rb package.new/vagrant-2.2.6/plugins/providers/virtualbox/driver/version_6_1.rb
--- package.orig/vagrant-2.2.6/plugins/providers/virtualbox/driver/version_6_1.rb   1970-01-01 01:00:00.000000000 +0100
+++ package.new/vagrant-2.2.6/plugins/providers/virtualbox/driver/version_6_1.rb    2019-12-13 10:39:42.119070431 +0100
@@ -0,0 +1,16 @@
+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
diff --unified --recursive --text --new-file package.orig/vagrant-2.2.6/plugins/providers/virtualbox/plugin.rb package.new/vagrant-2.2.6/plugins/providers/virtualbox/plugin.rb
--- package.orig/vagrant-2.2.6/plugins/providers/virtualbox/plugin.rb   2019-12-13 10:37:24.272748431 +0100
+++ package.new/vagrant-2.2.6/plugins/providers/virtualbox/plugin.rb    2019-12-13 10:39:01.200014546 +0100
@@ -59,6 +59,7 @@
       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

     module Model

Can we get this merged soon?

Using full wildcard versioning may be potentially more risky, but if semantic versioning (major.minor.patch) is used with VirtualBox (which appears to be the case) breaking changes should only happen on major version updates. Changes between minor or patch versions should be backward compatible.

With semantic versioning being used, it would be more ideal if Vagrant only displayed that error message with major version changes, like 5.x to 6.x, not with minor (or patch) version changes like 6.0.x to 6.1.x.

What drew my attention to this issue/error is that I'm using the vagrant & virtualbox Chocolatey packages for Windows, and when I did package upgrades, the virtualbox package was upgraded to a version not supported by the current version of the vagrant package.

For my uses, a simple fix is just to roll back the virtualbox package version to 6.0 and hold back upgrading it until the vagrant package version is updated to support virtualbox 6.1. This does not seem like a clean way of handling upgrades, though.

Another alternative may just be that the vagrant Chocolatey package needs to be dependent on specific versions of virtualbox instead of addressing this in vagrant itself. The vagrant Chocolatey package does not have any dependency on virtualbox at all, though, since vagrant can be used in provider agnostic ways that don't actually require using the virtualbox provider.

I have exactly the same issue as @michaelray and hope the problem will be fixed soon.

I had this issue multiple times now (at least with VirtualBox 6.0 as well) and would really appreciate if either Vagrant would become faster at supporting new VirtualBox versions or there was a way of ignoring the unsupported version warning.

I agree with @michaelray that a warning would be sufficient for changes to a minor. The whole point of semantic versioning is to allow for exactly this.

For Mac users, brew cask install virtualbox recently changed to install Virtualbox 6.1 . If you still want to install Virtualbox 6.0 with homebrew for use with Vagrant, use the following command to install the most recent formula that still installed 6.0:

brew cask install https://raw.githubusercontent.com/Homebrew/homebrew-cask/7e703e0466a463fe26ab4e253e28baa9c20d5f36/Casks/virtualbox.rb

I patched Vagrant on macOS with this script:

curl https://github.com/briancain/vagrant/commit/fb4e6985e142da56bad143d70600cd3695c91757.patch > /tmp/vagrant_226_virtualbox_610.patch
cd /opt/vagrant/embedded/gems/2.2.6/gems/vagrant-2.2.6
sudo git apply --verbose --exclude='website/*' /tmp/vagrant_226_virtualbox_610.patch

I'm also seeing this issue:

$ vagrant box update --provider=virtualbox                                                                                       master
The provider 'virtualbox' that was requested to back the machine
'tester-centos6-32' 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.

Any news about this issue?

Following change should also be managed:

A customization command failed:
["modifyvm", :id, "--clipboard", "bidirectional"]
The following error was experienced:

VBoxManage, a CLI

used by Vagrant
for controlling VirtualBox. The command and stderr is shown below.
Command: ["modifyvm", "ce8a3576-201c-11ea-978f-2e728ce88125", "--clipboard",
"bidirectional"]

VBoxManage CLI changed the option from "--clipboard" to "--clipboard-mode".
So, it seems that an important difference is there between VirtualBox 6.0 and 6.1.

Yes, this will be merged soon and included in the next release.

Was this page helpful?
0 / 5 - 0 ratings