Vagrant stuck connection timeout retrying

Question

My vagrant was working perfectly fine last night. I've just turned the PC on, hit vagrant up, and this is what I get:

==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
    default: Adapter 2: hostonly
==> default: Forwarding ports...
    default: 22 => 2222 (adapter 1)
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 127.0.0.1:2222
    default: SSH username: vagrant
    default: SSH auth method: private key
    default: Error: Connection timeout. Retrying...
    default: Error: Connection timeout. Retrying...
    default: Error: Connection timeout. Retrying...
    default: Error: Connection timeout. Retrying...
    default: Error: Connection timeout. Retrying...
    default: Error: Connection timeout. Retrying...
    default: Error: Connection timeout. Retrying...
    default: Error: Connection timeout. Retrying...
    default: Error: Connection timeout. Retrying...
    default: Error: Connection timeout. Retrying...
    default: Error: Connection timeout. Retrying...
    default: Error: Connection timeout. Retrying...
    default: Error: Connection timeout. Retrying...

Has anyone had this before? vagrant isn't widely covered on the web yet and I can't find a reason why this is occurring.

Answer 1

When you are stuck with your vagrant machine the way described above there is no need to boot in gui mode (and is impossible without an X server).

While your VM is booting, in a separate terminal window, just find out the id of the running machine.

vboxmanage list runningvms

This will result in something like this:

"projects_1234567890" {5cxxxx-cxxx-4xxx-8xxx-5xxxxxxxxxx}

Quite often, the VM is simply waiting for you to select an option in the bootloader. You can send the appropriate keycode (in the case, Enter) to the vm with controlvm:

vboxmanage controlvm projects_1234567890 keyboardputscancode 1c

That's it. Your virtual machine will continue the boot process.

Answer 2

I had the same issue when I was using x64 box(chef/ubuntu-14.04).

I changed to x32 and it worked(hashicorp/precise32).

Answer 3

What helped for me was the enabling the virtualization in BIOS, because the machine didn't boot.

Answer 4

Maybe this is too simple an answer to help a lot of people, but worth trying if you haven't: Do a "vagrant halt" instead of a "vagrant suspend" then restart the VM with "vagrant up".

I think my problem was due to some "kworker" process getting buggy and constantly timing out in the VM and so doing a hard reboot seemed to reload the process correctly whereas a save and restore was just restoring the broken process in its broken state.

Answer 5

I experienced the same issue on a Windows 8.1 machine. The connection timeout and enabling the gui was not usefull at all, the screen was black. The fix in my case was disabling "Hyper V"

Quote from Vagrant documentation https://docs.vagrantup.com/v2/hyperv/index.html

Warning: Enabling Hyper-V will cause VirtualBox, VMware, and any other virtualization technology to no longer work. See this blog post https://www.hanselman.com/blog/SwitchEasilyBetweenVirtualBoxAndHyperVWithABCDEditBootEntryInWindows81.aspx for an easy way to create a boot entry to boot Windows without Hyper-V enabled, if there will be times you'll need other hypervisors.

Answer 6

Rather than ctrl-d-ing out of the virtual box as I'm wont to do whenever I ssh into anything, I believe vagrant would prefer you get into another terminal and do a:

vagrant halt

to stop the box. Then there will be no issues getting back into the VB.