Vagrant ssh fails with VirtualBox

Question

vagrant up fails when it gets to the ssh part:

myterminal$ vagrant up
[default] VM already created. Booting if its not already running...
[default] Running any VM customizations...
[default] Clearing any previously set forwarded ports...
[default] Forwarding ports...
[default] -- ssh: 22 => 2222 (adapter 1)
[default] -- db2: 30003 => 30003 (adapter 1)
[default] Cleaning previously set shared folders...
[default] Creating shared folders metadata...
[default] Booting VM...
[default] Waiting for VM to boot. This can take a few minutes.
[default] Failed to connect to VM!
Failed to connect to VM via SSH. Please verify the VM successfully booted
by looking at the VirtualBox GUI.

Then when I subsequently try and connect using vagrant ssh or vagrant reload or similar, I get this:

myterminal$ vagrant reload
[default] Attempting graceful shutdown of linux...
SSH connection was refused! This usually happens if the VM failed to
boot properly. Some steps to try to fix this: First, try reloading your
VM with `vagrant reload`, since a simple restart sometimes fixes things.
If that doesn't work, destroy your VM and recreate it with a `vagrant destroy`
followed by a `vagrant up`. If that doesn't work, contact a Vagrant
maintainer (support channels listed on the website) for more assistance.

Please help! I'm really stumped.

Kind regards,

Luke

Solution 1

I saw this problem with my setup and eventually narrowed it down to the fact that I'd added a name onto the local hosts file. So I had:

127.0.0.1 localhost myname myalias

Removed the myalias which I'd added and it booted okay. Thanks to @saphirlazuli for the clue that it was networking related.

Solution 2

I have had the same problem with the box given in the "Getting started" of Vagrant site. My solution below is for this tutorial's box.

I find a solution here : https://github.com/mitchellh/vagrant/issues/391

1. in the VagrantFile, add the gui mode : config.vm.boot_mode = :gui
2. run vagrant up
3. in the gui, log with the user "vagrant" (password = "vagrant")
4. int the gui, run sudo /etc/init.d/networking restart, in /etc/network/interfaces file, you must now have a section with #VAGRANT-BEGIN [...]#VAGRANT-END
5. run vagrant reload on the physical machine

Solution 3

This is an intermittent problem for me, and definitely seems to be related to networking. I found some more helpful information at Vagrant GitHub issues #391 and #455. I tried deleting my unused host-only network in VirtualBox settings (as recommended as a potential fix in one of the GitHub issues) which didn't seem to help.

Starting in gui mode (as described in a previous answer) is a great way to debug/fix problems. I found that it's because for whatever reason, the VM cannot obtain an IP address on startup. Starting in GUI mode then logging in (vagrant/vagrant) and running sudo dhclient in the guest OS would retrieve the IP address and the Vagrant setup process would complete successfully.

Still looking for a permanent fix though.

Hope this helps!

[EDITED TO ADD]: A helpful suggestion was added to GitHub Issue #455 which involves adding the following config to your Vagrantfile:

config.ssh.max_tries = 150

This is currently working for me, and seems to make sense since the problem seems to be related to timeout - increasing the number of tries should increase the probability of the SSH process succeeding in time. It's an intermittent issue in the first place so I'll reserve judgement for a while, but fingers crossed it'll work! Thanks to karel1980 for suggesting the fix.

Solution 4

If vagrant up fails, I recommend the following:

1. Boot with gui mode: this helps to see if the image is broken (or e.g. what it does before the provisioning is started), set config.vm.boot_mode = :gui in your Vagrantfile
2. Debug logging: run the provisioning with debug, chef.log_level = :debug
3. Repackage the box: sometimes you need to install something before everything else runs - to bootstrap the bootstrapper. That's not really possible, so the easiest is to boot a vm without any provisioning, install whatever you need and re-package the box (vagrant box repackage foo, then vagrant import foo and then add foo in your Vagrantfile)

Note: gui mode can have other issues, e.g. for me no provisioning works with vagrant 0.7.5 when gui is enabled. It's still great to debug the actual box though.

Solution 5

My network card type was originally set to 82540EM. I changed it to Am79C973 and now Vagrant up works every time. I've started multiple VMs, even rebooted the host and it still works.

The command is:

VBoxManage modifyvm yourmachinename --nictype1 Am79C973

Remember to repackage and readd your box to Vagrant.

I'm running Debian Squeeze 64-bit as host and guests, using VirtualBox 4.1.16 on a Core i7-2600 machine.

View more solutions

Comments

[Andrew Vit]

This worked for me, thanks. I had Vagrant running before, then it stopped working with a new box. Any idea what causes it?

[Mickey Cheong]

What is the workaround if I want to preserve myalias?

[Anatoly]

sudo /etc/init.d/networking restart is worked for me, thanks!

[sparrovv]

I did restart, but in /etc/network/interfaces I don't have section with #VAGRANT-BEGIN [...]#VAGRANT-END, any clue why? Can I add it manually?

[Vladyslav Bondar]

sudo dhclient works too

[CodeGnome]

If you want to use an alias, the Debian/Ubuntu way is to keep the first line as just 127.0.0.1 localhost, but add a second line with your aliases, like so: 127.0.1.1 foo bar baz

[rtf]

OP is not using Windows 7.

[Artistan]

Thank you r.tanner.f -- No OS was specified, this helped me, hopefully helps others.

[Mark]

Don't know why you were downvoted, this seems like it could help other people

[Duke]

Deleting my unused host-only network in VirtualBox settings worked for me! Thank you!

[Jeremy Hajek]

It seems that this setting was depricated as of 1.3.X - github.com/berkshelf/berkshelf/pull/856

[Calin]

I get The following settings shouldn't exist: boot_mode

[Calin]

Got in the latest version you have to put v.gui = true for the provider config

[Andy]

I also fixed this problem by temporarily disabling bridged mode.

[Jeremy Hajek]

on local or remote system?