New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NAT interface disconnected at startup #7648

Closed
vadviktor opened this Issue Jul 26, 2016 · 25 comments

Comments

Projects
None yet
@vadviktor
Copy link

vadviktor commented Jul 26, 2016

Vagrant version

1.8.5

Host operating system

Windows 10

Guest operating system

Ubuntu 14.04.4

Vagrantfile

VAGRANTFILE_API_VERSION = '2'

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  config.vm.box = 'u365'

  config.ssh.private_key_path = 'vagrant_rsa'

  config.vm.network 'private_network', ip: '10.0.42.51'
end

Expected behavior

The VM boots as normal, the ssh client can connect to it, VB NAT interface is connected.

Actual behavior

The VM is unable to boot, ssh client unable to connect to it because the NAT interface is disconnected.

I know many other people have different cases here, for me none of their solution works, but inspecting the network connections of the VM showed it was always in disconnected mode.

Any hints? Is it a known issue? What could possibly misconfigure it to be started in disconnected state?

@DanHam

This comment has been minimized.

Copy link

DanHam commented Jul 26, 2016

@vadviktor I've come across this issue as well but with a CentOS 7.2 guest.

HostOS: OS X 10.10.5
Vagrant: 1.8.5
Virtualbox: 5.1.2r108956

I worked around the issue by adding the following in my Vagrantfile.

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

This comment has been minimized.

Copy link

vadviktor commented Jul 26, 2016

@DanHam Thank you for the snippet, I'll try it later and reflect with my findings.

For now I just manually reconnected the cable upon vagrant up as it was waiting and still didn't timed out.

@sethvargo

This comment has been minimized.

Copy link
Contributor

sethvargo commented Jul 26, 2016

Hi there,

I think this is a vbox issue and not a vagrant one. The solution DanHam mentioned above looks like a good option for now.

@sethvargo sethvargo closed this Jul 26, 2016

@darkengine-io

This comment has been minimized.

Copy link

darkengine-io commented Jul 26, 2016

This happened to me after updating to VirtualBox 5.1. Packer works with VirtualBox 5.1, but Vagrant always starts the NAT interface as disconnected on my systems. Downgrading or putting that customize line in fixes the problem for me.

@DanHam

This comment has been minimized.

Copy link

DanHam commented Jul 26, 2016

@sethvargo

I think this is a vbox issue and not a vagrant one.

I've taken the OVF built by packer and imported it into Virtualbox directly. I see the same behaviour with regard to the 'disconnected cable' which certainly seems to support your assessment!

All told it doesn't look as though 5.1 is a great release for Virtualbox...

@vadviktor

This comment has been minimized.

Copy link

vadviktor commented Jul 27, 2016

Thank you @DanHam , that custom override worked.

@t2d

This comment has been minimized.

Copy link

t2d commented Sep 29, 2016

Importing old boxes still works. It's definitely a problem with packing boxes. See hashicorp/packer#3757
Workaround of @DanHam works fine.

@hanachan1026

This comment has been minimized.

Copy link

hanachan1026 commented Dec 6, 2016

@DanHam This fixed my problem too.. It took too long to this problem... thank you!

@denis-chmel

This comment has been minimized.

Copy link

denis-chmel commented Dec 11, 2016

Thanks, @DanHam's fix helps. I had an issue with laravel's homestead, 'vagrant up' was freezing on:
homestead-7: SSH auth method: private key
and looking into VM console I saw:
A start job is running for raise network interfaces
which was attempting to do something during 5min and then vagrant up quit on timeout.
After changing Vagrantfile - vm has ran smoothly.

jarek-przygodzki pushed a commit to jarek-przygodzki/vagrant-swarm-mode-ol72-cluster that referenced this issue Dec 16, 2016

@4m3ndy

This comment has been minimized.

Copy link

4m3ndy commented Dec 16, 2016

Thanks @DanHam for the fix, this was what I exactly needed.

@Redsandro

This comment has been minimized.

Copy link

Redsandro commented Jan 18, 2017

This probably has something to do that these interfaces are now called e.g. enp1s0 in stead of eth1 etc.
The only thing that worked for me is upgrading to the 1.9.x Debian version.

Probably a good idea for Ubuntu users anyway, or they'll have difficulties controlling their blood pressure due to an inability to understand how fixes like e.g. vagrant-libvirt/vagrant-libvirt#575 aren't backported to the Ubuntu repository.

@DanHam

This comment has been minimized.

Copy link

DanHam commented Jan 18, 2017

This has now been fixed by the Virtualbox team. See the quote below or view the update from scoter-oracle directly here (scroll to the bottom of the page).

We worked on this issue and fixed it into 5.1 release of VirtualBox.
At the same time the issue will be fixed on 5.0 into the future release 5.0.32.
VirtualBox-team - Oracle

Long and short, if you are seeing this issue, upgrading to the latest and greatest Virtualbox release should fix it!

@Redsandro

This comment has been minimized.

Copy link

Redsandro commented Jan 18, 2017

Thanks @DanHam.

However, since Ubuntu 16.04 LTS will stay at Vagrant 1.8.x and VirtualBox 5.0.x for the next 6 years, we need to either get VirtualBox or Vagrant from external repositories until Ubuntu 18.04 LTS is released in 2018.

No problem at home, but managed environments often stick to LTS versions, and SLA's often exclude non-default-repo packages. Hence the never ending but often futile hope for downstream backports.

Perhaps these policy restrictions are a bit outdated, but they are still enforced.

tpouyer pushed a commit to stackinabox/stackinabox.io that referenced this issue Jan 21, 2017

@subimage

This comment has been minimized.

Copy link

subimage commented Feb 21, 2017

Chiming in that this is still an issue with latest released versions of Vagrant & VirtualBox.

Versions on OS X:

  • Vagrant 1.9.1
  • Virtualbox 5.1.15 r112924

Was banging my head against the keyboard for hours until I stumbled upon this issue and the workaround — which fixed things for me. Thanks @DanHam

@subimage

This comment has been minimized.

Copy link

subimage commented Feb 27, 2017

OK, false alarm. Now getting this issue again even with the "cableconnected" setting in place. Anyone have other fixes/ideas?

@aj-jester

This comment has been minimized.

Copy link

aj-jester commented Mar 9, 2017

@subimage Same here, it hangs even when adding cableconnected 😞

@subimage

This comment has been minimized.

Copy link

subimage commented Mar 9, 2017

@aj-jester It turned out the issue for me was the default debian/jessie64 box. Switching to "bento/debian-8.7" fixed this issue for me.

I've read elsewhere it has to do with some bug in older versions of the packaging software, which would indicate that switching boxes to one packed properly solved things.

@aj-jester

This comment has been minimized.

Copy link

aj-jester commented Mar 9, 2017

@subimage wow, you were right. I actually wanted CentOS 6.7 so I went back to a build from a year ago and it boots up fine 👍

@subimage

This comment has been minimized.

Copy link

subimage commented Mar 9, 2017

Awesome! I know it's a frustrating bug. I spent a good week before it got sorted. Was almost ready to give up on Virtualbox completely.

@jennaliu

This comment has been minimized.

Copy link

jennaliu commented Apr 6, 2017

@DanHam Thank you. It took me so long to get to this thread, but that solved my problem finally.

croomes pushed a commit to storageos/storageos.github.io that referenced this issue Apr 10, 2017

André Lucas
Work around VBox 5.1 bug
This is from DEV-847 - the NAT interface can sometimes start with its
cable disconnected. This manifests itself in the VM booting and
appearing to work, but never connecting via SSH. If you enable the
console (set STORAGEOS_GUI=true) you can see systemd hang on bringing up
network interfaces until you 'connect' interface 1.

From: hashicorp/vagrant#7648
@magicalbob

This comment has been minimized.

Copy link

magicalbob commented May 19, 2017

I was just having this issue today. Every time I started up my multi-machine Vagrantfile one or the more of the machines stuck with eth0 down. Eventually I just deleted the .vagrant file from the directory where the Vagrantfile was & all the machines started.

@jcowley

This comment has been minimized.

Copy link

jcowley commented Jul 26, 2017

This is still very much a bug and the recommended workaround above has no effect.

Host OS: Ubuntu 16.04 LTS
Guest OS: ubuntu/trusty32
Vagrant: 1.9.7
VirtualBox: 5.1.24

Vagrantfile:

VAGRANTFILE_API_VERSION = '2'

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  config.vm.box = 'ubuntu/trusty32'
  config.vm.provider 'virtualbox' do |vb|
    vb.customize ['modifyvm', :id, '--cableconnected1', 'on']
  end
end

vagrant up hangs on default: SSH auth method: private key and eventually times out.

@jcowley

This comment has been minimized.

Copy link

jcowley commented Jul 26, 2017

There are literally hundreds (maybe thousands) of threads about this particular vagrant/virtualbox behavior on the interwebs (30+ that I found in this repo alone). It seems like a number of underlying issues can cause it, and there's an endless amount of useless black magic tips out there to work around it.

For any other poor souls banging their head against the wall, the magic dust for me was enabling virtualization in the BIOS (see #8668). Thank you @dradetsky for posting it.

adyp added a commit to bsdcon/vagrant-docker-vm that referenced this issue Nov 8, 2017

martinmosegaard pushed a commit to martinmosegaard/kubernetes-training that referenced this issue Jan 8, 2018

Martin Mosegaard Amdisen
Remove cableconnected VirtualBox setting
Seems due to a bug fixed in VirtualBox 5.1:
hashicorp/vagrant#7648

martinmosegaard pushed a commit to martinmosegaard/kubernetes-training that referenced this issue Jan 9, 2018

Martin Mosegaard Amdisen
Remove cableconnected VirtualBox setting
Seems due to a bug fixed in VirtualBox 5.1:
hashicorp/vagrant#7648

tomjn added a commit to Varying-Vagrant-Vagrants/VVV that referenced this issue Jun 28, 2018

@MatheusRV

This comment has been minimized.

Copy link

MatheusRV commented Sep 28, 2018

Try add export VAGRANT_WSL_WINDOWS_ACCESS_USER_HOME_PATH="/mnt/c/temp" in bash and reopen your bash.

Works here on Windows 10 1803 17134.285 WSL vagrant 2.1.5 and vbox 5.2.18 r124319

charlestonsoftware pushed a commit to charlestonsoftware/VVV that referenced this issue Oct 2, 2018

@zacktagnan

This comment has been minimized.

Copy link

zacktagnan commented Oct 7, 2018

@MatheusRV I have also the same environment with Windows 10, VirtualBox 5.2.18 and Vagrant 2.1.5.
When I execute vagrant up to load Homestead VM the process stops at this line:
SSH auth method: private key
You said that you solve adding export VAGRANT_WSL_WINDOWS_ACCESS_USER_HOME_PATH="/mnt/c/temp" in bash and reopen your bash.

I don't understand what you to do.
Where do you put this line with the export command? I've try to put on the Vagrantfile but it fails when I execute vagrant up. So where exactly?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment