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.

Was it helpful?

Solution

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

OTHER TIPS

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. NAT cable connection

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

enter image description here

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.

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),
  • 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 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.

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 "myemailaddress@mydomain.com", 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.

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.

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

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

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top