vagrant hangs at Configuring network adapters within the VM after an unclean guest shutdown

[asoki]

i using vagrant Version: 1.7.4, with VMWare Fusion 7.1.2, my guest machine is a Debian Wheezy

after my guest os did freezed, i switched it off.

after that, when i invoked "vagrant up foo" vagrant get stuck at "Configuring network adapters within the VM" and after a while i get the error message:

[removed..]
DEBUG ssh: Re-using SSH connection.
 INFO ssh: Execute: /sbin/ifdown eth1 2> /dev/null (sudo=true)
DEBUG ssh: Sending SSH keep-alive...
DEBUG ssh: Sending SSH keep-alive...
DEBUG ssh: Sending SSH keep-alive...
DEBUG ssh: Sending SSH keep-alive...
DEBUG ssh: Sending SSH keep-alive...
DEBUG ssh: Sending SSH keep-alive...
DEBUG ssh: Sending SSH keep-alive...
DEBUG ssh: Sending SSH keep-alive...
DEBUG ssh: Sending SSH keep-alive...
DEBUG ssh: Sending SSH keep-alive...
ERROR warden: Error occurred: Operation timed out - recvfrom(2)
[removed..]
/opt/vagrant/embedded/gems/gems/net-ssh-2.9.2/lib/net/ssh/buffered_io.rb:65:in `recv': Operation timed out - recvfrom(2) (Errno::ETIMEDOUT)
    from /opt/vagrant/embedded/gems/gems/net-ssh-2.9.2/lib/net/ssh/buffered_io.rb:65:in `fill'
    from /opt/vagrant/embedded/gems/gems/net-ssh-2.9.2/lib/net/ssh/connection/session.rb:237:in `block in postprocess'
    from /opt/vagrant/embedded/gems/gems/net-ssh-2.9.2/lib/net/ssh/connection/session.rb:233:in `each'
    from /opt/vagrant/embedded/gems/gems/net-ssh-2.9.2/lib/net/ssh/connection/session.rb:233:in `postprocess'
    from /opt/vagrant/embedded/gems/gems/net-ssh-2.9.2/lib/net/ssh/connection/session.rb:212:in `process'
    from /opt/vagrant/embedded/gems/gems/net-ssh-2.9.2/lib/net/ssh/connection/session.rb:170:in `block in loop'
    from /opt/vagrant/embedded/gems/gems/net-ssh-2.9.2/lib/net/ssh/connection/session.rb:170:in `loop'
    from /opt/vagrant/embedded/gems/gems/net-ssh-2.9.2/lib/net/ssh/connection/session.rb:170:in `loop'
    from /opt/vagrant/embedded/gems/gems/net-ssh-2.9.2/lib/net/ssh/connection/channel.rb:269:in `wait'
    from /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/communicators/ssh/communicator.rb:589:in `shell_execute'
    from /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/communicators/ssh/communicator.rb:215:in `block in execute'
    from /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/communicators/ssh/communicator.rb:312:in `connect'
    from /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/communicators/ssh/communicator.rb:209:in `execute'
    from /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/communicators/ssh/communicator.rb:246:in `sudo'
    from /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/guests/debian/cap/configure_networks.rb:45:in `block (2 levels) in configure_networks'
    from /opt/vagrant/embedded/lib/ruby/2.0.0/set.rb:232:in `each_key'
[removed]

the FIX for this problem was to clean up the /etc/network/interfaces file manually and remove the #VAGRANT-BEGIN ... #VAGRANT-END part and shutdown the box. after that, the next vagrant up worked as expected.

i suspect the problem here is, that eth1 is already up after the boot and vagrant ssh-ing over the eth1 interface into the box and executes an ifdown for that interface.

i wish vagrant could clean up the /etc/network/interfaces file on "vagrant up"
or, after a timeout would try ssh into the box again (over the eth0 interface)

[asoki]

i don't know whats wrong here, but it seems that manually removing the vagrant modifications from the /etc/network/interfaces file is only a temporary solution. it works on the next vagrant up after the remove, and gets always stuck on the second vagrant up.

when i comment out the line 3, "auto eth<%= options[:interface] %>" in
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/templates/guests/debian/network_static.erb
and so the interface eth1 is not automatically up on boot seems to solve my problem.

why is there an auto ethN in the interfaces file when configure_networks brings down and up again all vagrant configured interfaces in /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/guests/debian/cap/configure_networks.rb

[hogepodge]

Seeing the same problem here.

[ironcladlou]

This happens to me ridiculously often. So far the VMware provider is far buggier than VirtualBox ever was, which is pretty ironic considering it's commercially supported.

[hogepodge]

Agree with that. One would presume that the upgrade cost one pays with every release of VMWare would cover fixing these persistent bugs. The VMWare provider is far less useful for me now than it was even a year ago.

[SolidState214]

Ditto... I see this quite frequently. Very frustrating.

This command seems to work around it for me. I wonder why Vagrant seems to stop the services in the first place?
sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-cli --start

[chrisroberts]

Hi there,

Thanks for reporting this bug. I'm sure this was a real issue when originally reported (our fault for not looking sooner!) but there have been multiple Vagrant releases since the original report. I'm going to close this issue now and request you reopen the issue if you're still experiencing this problem. I'm sorry this wasn't looked at earlier :frowning_face:

Cheers!

[mpepping]

Well, this is still an issue. In my experience the Fusion provider is reliable-ish when running Ent. Linux based boxes. These issues occur way more often /w boxes based on newer Linux distros (Fedora, Ubuntu).
There's definitely a reliability issue to address. Reopen?

Edit: Box quality is also an aspect. Overall the more 'credible' boxes, like the Bento boxes are more reliable.

[matthiaslink77]

Same problem until today. When is this going to be fixed? Seems to be related with adding another network interface to the box. If I omit any other interface like

vmware.vm.network :private_network, ip: "192.168.10.10"

the vagrant vm comes up without any issues.

Any ideas? Thanks. Matthias.

[NiklasA]

Hi,
currently I have the same issue with Centos and Virtualbox as provider. If I remove the private network, everything works fine. I can reproduce it on Mac and Windows.
Does anyone else still have this error?

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.