vagrant ssh only possible after restart network

[sebastian-alfers]

Hey,

i can not log into my VM after "vagrant up"

i have to start it in gui-mode, then retart my network adapter "sudo /etc/init.d/networking restart" after this, my VM gets an ip (v4) address and my mac is able to ssh the VM and do the provisioning.

any idea on this?

same isse as here: http://groups.google.com/group/vagrant-up/browse_frm/thread/e951417f59e74b9c

the box is about 5 days old!

Thank you! Seb

[searls]

I just ran into this error after setting up SSH agent forwarding for (OS X host). Removing config.ssh.private_key_path = "~/.ssh/id_rsa" fixed my issue.

[dukejones]

Try playing with: VBoxManage modifyvm "VM name" --natdnsproxy1 on and VBoxManage modifyvm "VM name" --natdnshostresolver1 on

Also if you don't mind altering your VM after the fact, @jphalip / @keo above suggest to add dhclient eth0 to /etc/rc.local.

[ghost]

Is there an agreed upon solution for this? I'm running VirtualBox 4.3.6 and Vagrant 1.4.1 on RHEL 6.2 and unable to run vagrant ssh. I see the Wiki page, but since I am accessing the host machine through SSH, I don't have access to VirtualBox GUI?

[shimondoodkin]

i had a problem the vagrant was freezing after restore from hibernate. in windows 7 after unchecking "enable switch off this device to save power", in wifi card driver(change adapter settings link on the side in network and sharing center,rightclick and properties on an adapter,configuration button), in power management options , the problem seems gone.

probably the problem is like a 'broken pipe' kind of problem. something with the network device. because network device is diconnected before hibernate and on startup

[cstewart87]

Seeing this issue running Vagrant 1.4.3 with Virtualbox 4.3.6r91406 on Ubuntu 12.04. Are there specific host network settings that are required for Vagrant to work correctly?

[kikitux]

Vagrant set and use local port 2222 to first nic on port 22

are you setting config.ssh ?

can you paste your vagrantfile ?

On Wed, Feb 26, 2014 at 11:59 AM, Curtis Stewart notifications@github.comwrote:

Seeing this issue running Vagrant 1.4.3 with Virtualbox 4.3.6r91406 on Ubuntu 12.04. Are there specific host network settings that are required for Vagrant to work correctly?

Reply to this email directly or view it on GitHubhttps://github.com/mitchellh/vagrant/issues/391#issuecomment-36069787 .

[cstewart87]

I'm using test-kitchen and this is the generated Vagrantfile:

Vagrant.configure("2") do |c|
  c.vm.box = "opscode-ubuntu-12.04"
  c.vm.box_url = "https://opscode-vm-bento.s3.amazonaws.com/vagrant/virtualbox/opscode_ubuntu-12.04_chef-provisionerless.box"
  c.vm.hostname = "host-ubuntu-1204.vagrantup.com"
  c.vm.synced_folder ".", "/vagrant", disabled: true
  c.vm.provider :virtualbox do |p|
    p.customize ["modifyvm", :id, "--memory", "512"]
  end
end

[kikitux]

@cstewart87 Worked for my with your vagrantfile, no issues at all.

[jean]

I added a public network to my VM. This booted fine and worked great. Then I tried to restart. Subsequently:

19:16 jean@klippie:~/vagrant/geonode$ VAGRANT_LOG=DEBUG vagrant halt
 INFO global: Vagrant version: 1.2.2
[...]
DEBUG subprocess: Waiting for process to exit. Remaining to timeout: 32000
DEBUG subprocess: Exit status: 0
DEBUG virtualbox_4_2:   - [1, "ssh", 2222, 22]
DEBUG ssh: Checking key permissions: /home/jean/.vagrant.d/insecure_private_key
 INFO ssh: Attempting SSH. Retries: 100. Timeout: 30
 INFO ssh: Attempting to connect to SSH...
 INFO ssh:   - Host: 127.0.0.1
 INFO ssh:   - Port: 2222
 INFO ssh:   - Username: vagrant
 INFO ssh:   - Key Path: /home/jean/.vagrant.d/insecure_private_key
DEBUG ssh: == Net-SSH connection debug-level log START ==
DEBUG ssh: D, [2014-03-10T19:16:53.664503 #12855] DEBUG -- net.ssh.transport.session[4caaa54]: establishing connection to 127.0.0.1:2222
D, [2014-03-10T19:16:53.665283 #12855] DEBUG -- net.ssh.transport.session[4caaa54]: connection established
I, [2014-03-10T19:16:53.665407 #12855]  INFO -- net.ssh.transport.server_version[4caa09a]: negotiating protocol version

DEBUG ssh: == Net-SSH connection debug-level log END ==
 INFO retryable: Retryable exception raised: #<Timeout::Error: execution expired>
 INFO ssh: Attempting to connect to SSH...
 INFO ssh:   - Host: 127.0.0.1
 INFO ssh:   - Port: 2222
[...] # repeats endlessly

[kikitux]

@jean I see you are posting in a bug that is closed, perhaps you want to try the mailing list.

I can tell you that I have seen issues when the vagrant file have some errors in the logic, or the base box had the issues.

you can send an email tot he mailing list, with the Vagrantfile and we can take it from there.,

[jean]

@kikitux thanks for your answer, posting to the list :bow:

[appsol]

@axsuul I am getting this issue with a CentOS box running on Ubuntu 12.04 host. The issue appeared after a kernel update in Ubuntu which caused the DKMS entry for VirtualBox to be corrupted. This may be related or may be coincidence. I tried several of the fixes here, but only adding /etc/init.d/networking restart to /etc/rc.local has let me get the box up and running again.

[stenver]

https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/797544

This is pretty much to root of the isse

[trkoch]

I ran into a similiar issue with Ubuntu 14.04 Cloud Image. Turns out Vagrant adds

post-up route del default dev $IFACE

to the interface configuration. Manually removing this before rebooting fixes the issue (i.e. I can immediately vagrant ssh and don't get any timeouts). However, Vagrant adds this snippet back when running the auto configuration on bootup.

[simonmorley]

Impressed there are people, including myself, still struggling with this.

[mrhassell]

Thank you @mikhailov ! The... /etc/rc.local > sh /etc/init.d/networking restart just before “exit 0″... worked a charm!

[donmccurdy]

Is there an equivalent of the /etc/rc.local > sh /etc/init.d/networking restart that will work without destroying and re-provisioning the vagrant? My current solution on Ubuntu 14.04 has involved destroying the vagrant whenever the issue happens to show up.

[Gowiem]

I'm experiencing this issue at least once a week and it's driving me nuts. Doing this from the wiki page fixes the issue but it is really time consuming and takes up a good chunk of my morning. I've tried a number of the fixes listed here and they haven't helped.

Is there no way to get a fix for this into Vagrant and skip this runaround of workarounds?

[matiasepalacios]

I came up with a fix that works fine so far for me.

Disclaimer: this is more a hack than a fix, as it does not solves the real problem, which I have no clue how to fix, however, it works...

Ok, so first, you have to make sure your /etc/networks/interface file is 'clean'. Mine looks like this:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface 
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth0
iface eth0 inet dhcp 
pre-up sleep 2

Then, once you make sure your file is ready, you just create a simple bash script, put it on /etc/init.d and add it to the startup of the VM:

#! /bin/sh
# /etc/init.d/interfaces.sh
#

### BEGIN INIT INFO
# Provides: crap
# Required-Start: 
# Required-Stop:
# Should-Start:
# Should-Stop:
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Does Vagrant related crap
# Description: More crap
### END INIT INFO

sudo cat /etc/network/interfaces > /etc/network/interfaces.bak

And to add it, you just run this command:

sudo /usr/sbin/update-rc.d interfaces.sh defaults

That will make a backup copy of your /etc/network/interfaces file, that you will copy over again when you shutdown the machine. The script that does it is as simple as the first one:

#! /bin/sh
# /etc/init.d/interfaces-at-shutdown.sh
#

### BEGIN INIT INFO
# Provides: crap
# Required-Start:
# Required-Stop:
# Should-Start:
# Should-Stop:
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Does Vagrant related crap
# Description: More crap
### END INIT INFO

sudo cat /etc/network/interfaces.bak > /etc/network/interfaces

and then you create a symbolic link to it on /etc/rc0.d like this:

sudo ln -s ../init.d/interfaces-at-shutdown.sh K01interfaces

and that's it. Every time the machine starts, it will backup the file, and every time it shutdown it will reverse the file to it's original state, thus, allowing Vagrant to do it's ssh magic.

[StyxOfDynamite]

I think shoe-horning all these issues into one has actually had a negative effect. that said here seems to be the only viable place to talk through the issues I'm facing.

Virtualbox fails to configure virtual network adapters when launched via vagrant up

I've literally read everything I can find on the various SSH timeout issues and there seems to be a few different "causes" each with their own "fixes"

None of these identify the actual issue I'm having.

I'm working on a Linux Host, With a Virtualbox Provider and I can't get a single box to launch successfully. Many prepackaged boxes won't launch as my physical chipset doesn't support 64 bit Virtualization (Despite supporting a 64 bit OS)

I've built a Vagrant Box from Scratch. I needed an easily producible, distributable ghost blog installation for theme development. To rule out issues with the created box I've also tried with several 32bit boxes that are already in existence.

If I launch the box with vagrant up at a high level the following things happen.

1 The box is imported from my list of boxes to the current directory 1 Network adapters are initialised 1 The VM boots 1 The VM hangs long enough that vagrant gives up trying to SSH 1 The VM continues to boot after waiting 2 minutes, it waits 60 seconds before waiting an additional 60 seconds and then launches without configured virtual network adapters.

At this point I cannot ssh into the box using either 'vagrant ssh' or 'ssh vagrant@127.0.0.1'

Now the box has been imported and the ports configured. I can use the Virtual Box GUI to send the shutdown signal.

If I then use the VirtualBox GUI to power on the machine the following things happen.

1 The VM boots 1 It uses the saved network configuration from the earlier failed attempt at booting 1 it does not hang 1 I can now use vagrant ssh | vagrant suspend without issues.

This to me suggests the issue I'm facing is with how vagrant up tells VirtualBox to launch the VM.

The Work-around (No Hacks vs No instant portability)

The workaround of killing the booted VM and then relaunching it via the GUI is not the end of the world, doesn't involve any hacks to any vagrant files. It does however mean I can't rely on vagrant to provision the machine (not a problem as I purpose built the base image to avoid keep provisioning machines in the same way. I do have to manually add shared folders once the machine has been imported. I can get by with this just fine for the time being but will look more closely at the difference between how the vagrant up launches the machine to how VirtualBox launches the machine when I can find time.

[nryoung]

I am going to put my fix here in case it helps somebody who had the same issue as me.

I received this error when trying to vagrant ssh in to my vm after provisioning:

ssh_exchange_identification: Connection closed by remote host

after changing my synced_folder setting to:

config.vm.synced_folder ".", "/var", type: "nfs"

Turns out this folder is owned by root thus creating this folder would fail on vagrant up and cause the networking portion of the vm to not be configured correctly. When I changed my synced_folder to:

config.vm.synced_folder ".", "/var/<dir not owned by root>", type: "nfs"

where <dir not owned by root> is a custom path. This allowed vagrant to provision the VM correctly and thus the networking to come up correctly and vagrant ssh worked as expected.

[Xitsa]

I have the same problem with virtualbox 5.0.2 and vagrant 1.7.4 on ubuntu 14.04 (all x86). For some reason eth0/eth1 are bound to ip6. I've changed in settings of VMs NIC type to Am79C973. After that vagrant connects to VM successfully.

[alexkart]

Thanks @Xitsa it works for me too, but not for all vms, for others works this:

ifdown eth0
sleep 1
ifup eth0
exit 0

to /etc/rc.local

upd: also, tried to enable intel virtualization in BIOS, and it helped as well, it seems virtualization is required even for 32 bit operation systems (ubuntu/trusty32)

[timmackinnon]

Thought I would add some details around the solution that I employed to work around this issue. This appeared on my end to be bound to the existence of a private network ... so something like this in my Vagrantfile:

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

The end result was mixed up eth0 and eth1 interfaces that when running with the VBox GUI enabled and logging in, looked something like the following:

[root@host0 ~]# nmcli connection show
NAME     UUID                                  TYPE            DEVICE  
docker0  df9293c9-051e-4005-81a1-f08a4e9fdccf  bridge          docker0 
eth0     5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03  802-3-ethernet  eth1    
[root@host0 ~]# nmcli dev status
DEVICE   TYPE      STATE        CONNECTION 
docker0  bridge    connected    docker0    
eth1     ethernet  connected    eth0       
eth0     ethernet  disconnected --         
lo       loopback  unmanaged    --

My solution, and it is kind of hacky, was to employ a systemd service to clean this up at boot time. It looks like the following:

[Unit]
Description=Service to clean up eth0 and eth1
Wants=network-online.target
After=network.target network-online.target

[Service]
Type=simple
ExecStartPre=-/usr/bin/echo "Network clean up started"
ExecStartPre=-/usr/bin/sleep 5
ExecStartPre=-/usr/bin/nmcli connection delete eth0
ExecStart=/usr/bin/nmcli connection add type ethernet ifname eth0 con-name eth0
ExecStartPost=-/usr/bin/echo "Network clean up completed"
[Install]
WantedBy=multi-user.target

and to push my private network config up to the Vagrant layer:

config.vm.network "private_network", ip: "192.168.42.2", auto_config: false
config.vm.provision "shell",
  run: "always",
  inline: "ifconfig eth1 192.168.42.2 netmask 255.255.255.0 up"

so it runs after vagrant can ssh into the VM.

When running the following:

#!/bin/bash
for i in {1..100}
do
   echo "#### Iteration $i started ####"
   vagrant up
   vagrant destroy -f
   echo "#### Iteration $i completed ####"
done

I was able to get my VM to come up 100/100 times.