NAT interface disconnected at startup

[vadviktor]

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]

@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]

@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]

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.

[darkengine-io]

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]

@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]

Thank you @DanHam , that custom override worked.

[t2d]

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

[hanachan1026]

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

[denis-chmel]

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.

[4m3ndy]

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

[Redsandro]

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 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]

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.

[subimage]

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]

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

[aj-jester]

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

[subimage]

@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]

@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]

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]

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

[magicalbob]

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 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]

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.

[matbrgz]

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

[zacktagnan]

@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?

[ghost]

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.