Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Virtualbox 6.1 #11249

Closed
rreynier opened this issue Dec 11, 2019 · 21 comments
Closed

Support Virtualbox 6.1 #11249

rreynier opened this issue Dec 11, 2019 · 21 comments

Comments

@rreynier
Copy link

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

@piotr-cz
Copy link

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

...

@rodrigoprimo
Copy link

Workaround available here: oracle/vagrant-projects#178 (comment)

@scoter-oracle
Copy link

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

@SilverPreece
Copy link
Contributor

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.

@scoter-oracle
Copy link

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.

@SilverPreece
Copy link
Contributor

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.

@scoter-oracle
Copy link

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 ?

@briancain
Copy link
Member

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! ❤️

@scoter-oracle
Copy link

@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 ?

@invidian
Copy link

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 --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

@breisig
Copy link

breisig commented Dec 13, 2019

Can we get this merged soon?

@michaelray
Copy link

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.

@michaelray
Copy link

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.

@simontunnat
Copy link

simontunnat commented Dec 14, 2019

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.

@rreynier
Copy link
Author

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.

@bbkane
Copy link

bbkane commented Dec 14, 2019

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

@lunaticare
Copy link

lunaticare commented Dec 14, 2019

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

@mikemadden42
Copy link

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.

@pedrofurtado
Copy link
Contributor

Any news about this issue?

@scoter-oracle
Copy link

scoter-oracle commented Dec 16, 2019

Following change should also be managed:

A customization command failed:
["modifyvm", :id, "--clipboard", "bidirectional"]
The following error was experienced:
#<Vagrant::Errors::VBoxManageError: There was an error while executing 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.

@chrisroberts
Copy link
Member

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

@hashicorp hashicorp locked as resolved and limited conversation to collaborators Dec 16, 2019
briancain added a commit that referenced this issue Dec 16, 2019
Fixes #11249: Add VirtualBox provider support for version 6.1.x
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.