Vagrant stuck connection timeout retrying

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.

I solved this problem, and will answer in case anyone else has a similar issue.

What I did was: I enabled the GUI of Virtual box to see that it was waiting for input on startup to select whether I wanted to boot directly to ubuntu or safemode etc.

To turn on the GUI you have to put this in your vagrant config Vagrantfile:

config.vm.provider :virtualbox do |vb|
  vb.gui = true
end

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.

One thing to double check is if Hardware Virtualisation is enabled in your machine's BIOS.

My problem is the same string of timeouts but I could only see a black screen in the GUI.

A laptop which I was just setting up kept showing the same problem. After hours of searching I finally found a tip to see if the BIOS had Hardware Virtualisation was enabled.

Here's the content of the post I found:

I see there are still some users who are experiencing this issue. So, I will attempt to summarise a list below of some possible solutions to the SSH timeout problem:

• Make sure your firewall or antivirus is not blocking the program (which I doubt will happen often)
• Give your vagrant machine some time for timeouts to happen. If you dont have a very fast PC / Mac, the VM will take while to boot into an SSH ready state, so timeouts will happen.
• Therefore, first try to let vagrant timeout COMPLETELY before concluding that there is a fault.
• If vagrant times out completely then increase the timeout limit in the vagrant file to a few min and try again.
• If that still doesnt work, then try to clean boot your vagrant machine through the VirtualBox interface and enable the GUI of the machine beforehand. If the GUI doesn't show anything happening (ie. just blackscreen, no text) while it is booting, then your vagrant machine has got problems.
• Destroy the entire machine through the VB interface and reinstall.
• Delete the ubuntu image files in the Vagrant Images folder in the user folder and redownload and install.
• Do you even have an intel processor that supports 64bit hardware virtualisation? Google it. If you do, make sure there is no setting in your Bios disabling this feature.
• Disable hyper-v feature if you are running windows 7 or 8. Google how to disable.
• Make sure you are running through an SSH enabled client. Use Git bash. Download: http://git-scm.com/downloads
• Install a 32bit version of ubuntu like trusty32 or precise32. Just change the version in the vagrant file and reinstall vagrant in new directory.
• Make sure you are using the latest vagrant and virtualbox versions. Last resorts: Format your computer, reinstall windows and buy an intel core isomething processor.

Hope that helps.

The solution I've found is to check the cable connection option in the adapter 1 which is attached to NAT. I really don't know, this is my 4th vagrant box but this is the only one with cable connection option not checked, and upon checking it, it works.

I had exact the same problem. I thought the problem might be with SSH keys (wrong localization of file or something else but I checked it many times) but you may always add in configure section username and password (without using ssh keys) and running gui so the code in Vagrantfile should look like more or less as below:

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
           
  config.ssh.username = "vagrant"
  config.ssh.password = "vagrant"
  
   config.vm.provider "virtualbox" do |vb|
     vb.gui = true
   end
end

In my case even if GUI was displayed I got black screen (no errors or possibility to login or anything else) and in console I got the Error: Connection timeout. Retrying... many times. I made sure I had VT-x (virtualization) enabled in BIOS, I checked many combinations of versions of both Virtual Box and Vagrant together and many Vagrant boxes (for some of them I didn't have black screen in GUI but still have connection problems). Finally I've updated VirtualBox and Vagrant again to the last versions and the problem still occurred.

The crucial thing was looking at icons in VirtualBox after running vagrantup (with GUI in Vagrantfile as I showed above) as on the below image

Although I had no errors in VirtualPC (no warnings that VT-x is not enabled) my V icon was earlier gray so it means the VT-x was disabled. As I said I had it enabled in my BIOS all the time.

Finally I realized the problem might by HYPER-V which I also installed and enabled to test sites on older Internet Explorer. I went to Windows Control Panel -> Programs and functions / Software and choose from the menu on left Turn on or Turn off Windows functions (hope you will find those, I use Polish Windows so don't know exact English names). I turned off Hyper-V, restarted PC and after running Virtual Box and vagrant up I finally had no errors, in GUI I have login screen and my V icon stopped to be gray.

I wasted a lot of time solving this issue (and many PC restarts) so I hope this might be helpful to anyone that have problem on Windows - make sure you have Hyper-V turned off in your Control Panel.

Mine was running fine and then this "Warning: Remote connection disconnect. Retrying..." over and over - maybe 20 times - until it connected. Based on answers above I just

vagrant destroy
vagrant up

and it was all good. Mine was very simple but I made it that way by cutting down the Vagrantfile to just the config.vm.box = "ubuntu/trusty64" and it was still doing it. So that is why destroying and starting again seemed the best choice. Given the stateless nature of these Vagrant images I don't see why that wouldn't work in every case. I'm just getting into this and I may yet learn that that isn't true.

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.

If you are working on Windows 8 or 10, this is what worked for me:

1. Change BIOS settings to allow virtualization of 64bit.
2. Here is how:
   • Restart PC using Advanced Startup (Go to Advanced Startup -'restart now'-'troubleshoot' -'advanced option'- 'UEFI Firmware Setting' - 'Restart')
   • Inside BIOS window - Go to 'Advanced' menu/tab - Enable 'Intel Virtual Technology'
   • Save & Exit.

I had an issue with this with an existing box (not sure what changed), but I could connect via SSH, even though the Vagrant box failed to boot up. As it happens my SSH key had changed somehow.

From the vagrant root folder I ran vagrant ssh-config which told me where the key file was. I opened this with puttygen and then it gave me a new key.

On my Linux guest, I edited ~/.ssh/authorized_keys and dropped the new public key in there.

Everything is working again - for now!

I had the same issue after I deleted this line from my Vagrantfile:

config.vm.network "private_network", type: "dhcp"

VM loaded fine after I put this line back.

I was testing a mounted folder in my vagrant VM by adding a new entry into /etc/fstab. Later on I logged out, ran vagrant halt, but when I ran vagrant up I got:

SSH auth method: private key
Warning: Remote connection disconnect. Retrying...

I read all these posts and tried all the ones that seemed relevant for my case (except for vagrant destroy, which would have certainly fixed my problem, but was a last resort in my case). The post by @Kiee gave me the idea to try to boot my VM directly from the VirtualBox GUI. During the boot process the VM halted itself and was asking me if I wanted to skip mounting the test folder that I had added earlier to /etc/fstab. (That's why vagrant couldn't boot the VM.) After answering 'NO' the VM booted no problem. I logged in, removed the naughty line from my fstab, and shutdown the VM.

After that vagrant was able to boot just fine.

Takeaway? If all of a sudden vagrant cannot boot back into your VM, try to boot directly from the provider (VirtualBox in my case). Chances are your boot is hanging for something totally unrelated to SSH.

The SSH connection timeout during initial booting may be related to variety of reasons such as:

• check whether virtualization is enabled in BIOS (as per comment),
• system awaits for user interaction (e.g. [share partition is not ready] 2),
• mismatch of your private key (check the config via vagrant ssh-config),
• the booting process takes much longer time (try increasing config.vm.boot_timeout),
• it's booting from the wrong drive (e.g. from the installer ISO),
• VM firewall misconfiguration (e.g. iptables configuration),
• local firewall rules, port conflict or conflict with a VPN software,
• sshd misconfiguration.

To debug the problem, please run it a --debug option or like:

VAGRANT_LOG=debug vagrant up

If there is nothing obvious, then try to connect to it from another terminal, by vagrant ssh or by:

vagrant ssh-config > vagrant-ssh; ssh -F vagrant-ssh default

If the SSH still fails, try to run it with a GUI (e.g. config.gui = true).

If it's not, check the running processes (e.g. by: vagrant ssh -c 'pstree -a') or verify your sshd_config.

---

If it is disposable VM, you can always try to destroy it and up it again.

You should also consider upgrading your Vagrant and Virtualbox.

---

For more information, check the Debugging and Troubleshooting page.

I had the same issue, but none of other answers fully solved my problem. Answer by @Kiee was helpful, although all I could see in the GUI was a black screen (with underscore in top-left, this issue in Virtual Box also has been raised separately in stack overflow, again nothing helped).

Eventually, a solution proved to be very simple: check version of your virtual machine.

More precisely, I had a box from someone else with 64-bit Debian, but Virtual Box insisted to treat it as 32-bit, what I didn't notice. To change it, open Virtual Box, then open terminal and run

vagrant up

wait for the line

default: SSH auth method: private key

now you can hit ctrl+C (or wait for timeout) and run

vagrant halt

your virtual machine won't be destroyed, so you can see it in the menu of Virtual Box, but will be powered off, so you can change settings. Chose your machine in the menu, click 'Settings'->'General' and chose proper 'Version', for me it was 'Debian (64-bit)'. After this type vagrant up again.

If this is a case for you (or different changes in 'Settings' solved your issue), you can create new box from the repaired one typing

vagrant package --output mynew.box

Some more details: host 32-bit Ubuntu 12.04, guest 64-bit Debian 8.1, Virtual Box 5.0.14, Vagrant 1.8.1

There are many good answers here, and I couldn't read it all, but, I just came by to gave my little contribution too. I had 2 different problems:

1. vagrant up wasn't able to find my ssh 'id_rsa' (because I didn't have it yet, at that time): I ran ssh-keygen -t rsa -b 4096 -C "[email protected]", based on this GitHub's article, and voilá, steped through that;

2. Then, I got the same problem of this question "Warning: Connection timed out. Retrying...", eternally...: So, after reading a lot, I've restarted my system and looked at my BIOS (F2 to get there, on PC), and there were Virtualization disabled. I've enabled that, saved, and started the system once again, to check if it has changed anything.

After that, vagrant up worked like a charm! It's 4am but it is running! How cool, hã? :D As I know there are very few masochist developers like me, that would try this at Windows, specially at Windows 10, I just couldn't not to forget coming here and left my word... another important information, is that, I was trying to set-up Laravel 5, using Homestead, VirtualBox, composer etc. It has worked. So, hope this answer helps like this question and answers helped me. My best wishes. G-bye!

I've found out that on MacOS with VirtualBox adding this to Vagrantfile will let you go further:

config.vm.provider 'virtualbox' do |vb|
  vb.customize ['modifyvm', :id, '--cableconnected1', 'on']
end

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

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

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.

I got this when running vagrant/VirtualBox inside VirtualBox. I resolved this by running the vagrant machine in the host machine.

Installing an ubuntu32 bits on an AMD64 bits did the trick. I don't have access to the BIOs since its a restricted environment, but i was still able to get it to work with ubuntu/trusty32 instead of ubuntu/trusty64

Using Vagrant 1.6.3 with VirtualBox 4.3.15 on Windows 7 SP1

hope that helps.

Delete the file:

C:\Users\UserName\\.vagrant.d\insecure_private_key

Then run:

vagrant up

For me it was the compatibility between vagrant and virtual box.

I'm on windows 10 and what I did I uninstalled vagrant and virtual box

Then install an old version of virtual box specifically version 4.3.38 ( Install extension pack too for this version )

Then installed latest copy of vagrant ( 1.8.5 at the moment )

After that it worked.

If you don't want to enable the GUI and then have to disable it later, you could also install the extension pack from Oracle:

http://www.oracle.com/technetwork/server-storage/virtualbox/downloads/index.html#extpack

Then put this in your Vagrantfile to enable VRDP:

vb.customize ["modifyvm", :id, "--vrde", "on"]

Now you can use RDP to connect to your box on demand without SSH needing to be running or the GUI open all the time.

What worked for me was allowing 64 bit virtualization on a 64 bit OS (Ubuntu 13.10) from BIOS.

One more possible solution for users of the VMware provider: For me the issue was resolved after removing a parallel installation of VirtualBox on the same host machine. Network interfaces between VMware and VirtualBox were apparently conflicting

I have faced the same problem. I fixed this by enabling Virtualization from BIOS setup.

Like some people here already pointed out, the error appears - among other things - if the VirtualBox image did not boot properly. For me using the GUI mode on Vagrant did not help much as it only showed a black window. In the VirutalBox GUI I checked the settings on my VM and figured out that somehow the OS was set incorrectly (Debian 32 instead of 64 Bit).

So I can only recommend checking the VirtualBox settings of the VM manually and getting the VM to boot without using Vagrant in first place.

Check your CPU's virtualization in BIOS setup is enabled.

In my case, giving it a static IP address, simply solved the problem:

config.vm.network "private_network", ip: "192.168.50.50"

I'm just sharing this so that it may help another person in future. rubo77 above gave me the inspiration for this answer.

I encountered this getting stuck in a connection timeout loop after uncommenting two lines in my vagrant file.

vb.gui="true"
config.vm.network "forwarded_port", guest: 80, host: 8080

Apparently the 1st line brings up the GUI which asks if you want to skip mounting or let vagrant mount manually. Commenting it back allowed me to log in, however I could still see 'Connection Aborted. Retrying' in the terminal.

So i ssh into my vagrant and typed.

sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Then vagrant reload and did not encounter any connection error. However take not this accepts all incoming traffic. So u might want to add rules to only allow port 8080 if you are going to use your bos for a long time.

Digital Ocean gives a very nice tutorial on adding rules to your iptables.

Remember to install iptables-persistent to save your firewall config

encountered similar issue for ubuntu/bionic64

by enabling the gui in Vagrantfile, i was able to login using default vagrant/vagrant

config.vm.provider "virtualbox" do |vb|
   vb.gui = true
end  

then reset the firewall using the following command

$ ufw force --reset  

then rebooted the system now this time without UI
was able to boot in without any issues

make sure to keep the backup of firewall rules before doing reset

FWIW-- My problem was due to using a really old config file instead of a newer one. Using the new configuration file (and thus tweaked/changed DSL) fixed my problems instantly.

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

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.

I faced the same issue, however non of the mentioned solutions worked for me! I solved it by downgrading Vagrant to 1.6.2 and now it works!

I had the same trouble with Vagrant 1.6.5 and Virtual Box 4.3.16. The solution described at https://github.com/mitchellh/vagrant/issues/4470 worked fine for me, I just had to remove VirtualBox 4.3.16 and install the older version 4.3.12.

It used to help to switch to trusty32, but the situation now got worse again: I tried to use Homestead 2.0 and now I've got the Connection Timeout problem again, which would't usually be a problem, because switching to 32bit helped before. But now I can't just add a line like config.vm.box="ubuntu/trusty32" because we don't have a classic Homestead.yaml file anymore, the values in the new 2.0 Homestead.yaml file just seem to be inserted into the real one in the background and there ist no Vagrantfile available that I could manually edit ...

Hope someone can help ...

From the virtualbox interface, I booted on a "CD" first, and disabled the hard drive boot. Hence it was booting on from a CD iso, and obviously not on the expected machine... I hope it helps. And I hope it made someone smile too... PEBCAK.

Disabled iptables firewall inside the VM

This is how I solved it:

• I enabled the GUI interface in my Vagrantfile (this is the config file)
• I could login into the running VM in the Gui with the standard username vagrant and password vagrant
• I disabled the running iptables firewall inside the VM

This solved my problem, I found out, that the firewall blocked all IPs from local networks like 192.168.x.x and 10.x.x.x

Adding a rule in /etc/iptables.d/199-allow-wan to allow all connections from wan:

ip46tables -A wan-input -j ACCEPT

(ip46tables is an alias) see this commit in my Vagrant example Freifunk community

Personally, for me, Tunnelblick VPN software was blocking the connection. Now when I'm booting up new VMs I temporary disable Tunnelblick.

If you're using a wrapper layer (like Kitchen CI) and you're running a 32b host, you'll have to preempt the installation of Vagrant boxes. Their default provider is the opscode "family" of binaries.

So before kitchen create default-ubuntu-1204 make sure you use:

vagrant box add default-ubuntu-1204 http://opscode-vm-bento.s3.amazonaws.com/vagrant/virtualbox/opscode_ubuntu-12.04-i386_chef-provisionerless.box

for using the 32b image if your host doesn't support word size virtualization

Look for this line in your Homestead.yaml:

config.vm.network "forwarded_port", guest: 80, host: 8080

and change to:

config.vm.network "forwarded_port", guest: 80, host: 8000

then in Homestead directory, run:

vagrant destroy
vagrant up

See if it works.

I solved by just typing ˆC(or ctrl+C on Windows) twice and quitting the connection failure screen.

Then, I could connect via SSH (vagrant ssh) and see the error by my own.

In my case, it was a path mistyped.

The way I had to solve this wasn't mentioned in this thread, so I'm posting the details here in case it helps anyone else.

What causes this is that vagrant can't ssh into the machine after it boots up. There's various reasons for this, as mentioned in this thread, such as the machine not booting up all the way, or iptables firewall blocking SSH.

In my case, the problem was that I inadvertently setup a "private_network" with an IP address in the same subnet as the built-in VirtualBox NAT network (in my case 10.0.2.0/24). This messed up the NAT network for the machine (but no errors shown anywhere), and since vagrant connects via the NAT network, it wasn't able to connect even though the machine was running and no firewalls were enabled.

Vagrant.configure("2") do |config|
  config.vm.network "private_network", ip: "10.0.2.31"
end

The fix was to update my VagrantFile and use a "private_network" IP that didn't conflict with VirtualBox's NAT network.

Vagrant.configure("2") do |config|
  config.vm.network "private_network", ip: "10.0.4.31"
end

I got it resolved when I killed putty process. Because I have git-ssh and putty both running. They were appearing to fight each other for ssh accessing. Only one is enough.

My solution to this issue was that my old laptop was taking wayyyyyyyyyyy too long to start up. I opened Virtual Box, connected to the box and waited for the screen to load. Took about 8 minutes.

Then it connected and mounted my folders and went ahead.

just be patient sometimes!

My solution turned out to be none of the above exactly. I'm running Ubuntu 14 as guest inside a Windows 7 host. I had been running this vagrant box fine, but I started it up again after not using it for a couple of months, and it kept coming up with the SSH connection timeout. It turned out that somehow the key pair didn't work - so I copied the Vagrant public key into Ubuntu according to the instructions on this page. But that wasn't all. I then discovered that the private key in my base box was different than the private key here. Putting this private key in as the vagrant_private_key file in C:\Users\your-user.vagrant.d\boxes\vagrant-box-name\nnnnnnnn\virtualbox after placing the public key into Ubuntu fixed the problem.

Here is how it worked for me:

> After "vagrant up" started the virtual machine, turned off the machine and go to the new virtual machine settings in virtualbox. Then go to "Network" -> "Advanced" > > Adapter Type: I changed from "Intel PRO XXXXX" to "PCNet-Fast" (or any other adpter other than Intel PRO did work)

Had this issue for more than one week, Tried all solutions,

1. giving SSH username and password
2. Enabling GUI interface
3. Updated Virtual Box and Vagrant

Nothing worked.

Finally got the solution from this link

Add the Google public DNS IP to your Wifi Settings

under Network Preferences > Wifi > Advanced > DNS add IP Address 8.8.8.8

Worked perfectly. May be this helps anyone who have problem in Mac. Thanks Skovmand

It's a new 'feature' of vagrant. Take a look here: https://github.com/mitchellh/vagrant/issues/3329

They will change the 'Error' to 'Warning'. It's just telling you that the machine isn't booted yet, and it's trying to connect...