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
Comments
@vadviktor I've come across this issue as well but with a CentOS 7.2 guest. HostOS: OS X 10.10.5 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 |
@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 |
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. |
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. |
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... |
Thank you @DanHam , that custom override worked. |
Importing old boxes still works. It's definitely a problem with packing boxes. See hashicorp/packer#3757 |
@DanHam This fixed my problem too.. It took too long to this problem... thank you! |
Thanks, @DanHam's fix helps. I had an issue with laravel's homestead, 'vagrant up' was freezing on: |
Thanks @DanHam for the fix, this was what I exactly needed. |
This probably has something to do that these interfaces are now called e.g. 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. |
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).
Long and short, if you are seeing this issue, upgrading to the latest and greatest Virtualbox release should fix it! |
Thanks @DanHam. However, since Ubuntu 16.04 LTS will stay at Vagrant 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. |
Chiming in that this is still an issue with latest released versions of Vagrant & VirtualBox. Versions on OS X:
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 |
OK, false alarm. Now getting this issue again even with the "cableconnected" setting in place. Anyone have other fixes/ideas? |
@subimage Same here, it hangs even when adding |
@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. |
@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 |
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. |
@DanHam Thank you. It took me so long to get to this thread, but that solved my problem finally. |
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
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. |
This is still very much a bug and the recommended workaround above has no effect. Host OS: Ubuntu 16.04 LTS Vagrantfile:
|
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. |
Seems due to a bug fixed in VirtualBox 5.1: hashicorp/vagrant#7648
Seems due to a bug fixed in VirtualBox 5.1: hashicorp/vagrant#7648
Try add Works here on Windows 10 1803 17134.285 WSL vagrant 2.1.5 and vbox 5.2.18 r124319 |
@MatheusRV I have also the same environment with Windows 10, VirtualBox 5.2.18 and Vagrant 2.1.5. I don't understand what you to do. |
I'm going to lock this issue because it has been closed for 30 days 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. |
Vagrant version
1.8.5
Host operating system
Windows 10
Guest operating system
Ubuntu 14.04.4
Vagrantfile
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?
The text was updated successfully, but these errors were encountered: