Vagrant: Hang at `Configuring and enabling network interfaces...` when using private_network with a static IP

[karlkfi]

Vagrant version

1.8.6

Host operating system

Mac OS 10.10.5

Guest operating system

CentOS 7

Host-only Network

network_name="$(VBoxManage hostonlyif create | grep "successfully created" | sed "s/Interface '\(.*\)' was successfully created/\1/")"
VBoxManage hostonlyif ipconfig --ip 192.168.65.1 "${network_name}"

Vagrantfile

Vagrant.configure(2) do |config|
  config.vm.define "dcos-centos-virtualbox" do |vm_cfg|
    vm_cfg.vm.box = 'mesosphere/dcos-centos-virtualbox'
    vm_cfg.vm.box_url = 'http://downloads.dcos.io/dcos-vagrant/metadata.json'
    vm_cfg.vm.box_version = '0.7.0'

    vm_cfg.vm.provider "virtualbox" do |v, override|
      v.name = "dcos-centos-virtualbox"
      v.cpus = 2
      v.memory = 2048
      v.customize ['modifyvm', :id, '--natdnshostresolver1', 'on']
      override.vm.network :private_network, ip: '192.168.65.10'
    end
  end
end

Expected behavior

1. Machine should initially come up with a DHCP IP (enp0s3).

2. Vagrant should add a new iface (enp0s8) to be a Static IP iface (on the host-only network).

   Actual behavior

3. Machine initially comes up with a DHCP IP (enp0s3).

4. Vagrant hangs executing the script to reconfigure the network interfaces.

Last ui output is Configuring and enabling network interfaces...

Vagrant seems to be hanging inside of the redhat-specific version of configure_networks.

Using a monkeypatch to replace configure_networks and add logging, I was able to determine that /etc/sysconfig/network-scripts/ifcfg-enp0s3 is being reconfigured from a dhcp iface to a static IP iface. Then the dchp iface is being brought down while vagrant is still connected. Vagrant then hangs - the ssh command never returns.

Steps to reproduce

vagrant up

References

Sounds like it might be related to https://github.com/mitchellh/vagrant/pull/7866

[karlkfi]

Adding another debug, I see network_interfaces is returning ["docker0", "enp0s3", "enp0s8"] instead of ["enp0s3", "enp0s8", "docker0"] so it does appear to be caused by the network_interfaces ordering bug.

[karlkfi]

I monkey patched in #7866 and confirmed that it does indeed fix this issue.

With it, the machine comes up with the following:

$ ifconfig
docker0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 172.17.0.1  netmask 255.255.0.0  broadcast 0.0.0.0
        ether 02:42:2d:6f:40:9a  txqueuelen 0  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp0s3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.0.2.15  netmask 255.255.255.0  broadcast 10.0.2.255
        ether 08:00:27:ca:ee:51  txqueuelen 1000  (Ethernet)
        RX packets 1203  bytes 122948 (120.0 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 823  bytes 105010 (102.5 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp0s8: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.65.90  netmask 255.255.255.0  broadcast 192.168.65.255
        ether 08:00:27:37:d8:1c  txqueuelen 1000  (Ethernet)
        RX packets 4  bytes 696 (696.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 11  bytes 1086 (1.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 0  (Local Loopback)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp0s3 is DHCP and enp0s8 is host-only static IP, which is the same behavior as Vagrant 1.8.4

[karlkfi]

For the record, monkey patching instructions:

1. Download the raw patched network_interfaces.rb into the same directory as your Vagrantfile
2. Prepend the following to the new network_interfaces.rb:

ruby require Vagrant.source_root.join('plugins/guests/linux/cap/network_interfaces.rb')

1. Prepend the following to your Vagrantfile:

ruby require_relative 'network_interfaces'

[ageis]

Same issue on Debian (stretch, sid, and jessie) GNU/Linux with Vagrant 1.8.6, and a Debian or Ubuntu guest. With a specific IP address configured in my Vagrantfile like so:

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

Vagrant hangs forever at Configuring and enabling network interfaces...

[ageis]

The mentioned patch from @chrisroberts does not resolve the issue for me on Linux. I even attempted to replace /opt/vagrant/embedded/gems/gems/vagrant-1.8.6/plugins/guests/linux/cap/network_interfaces.rb with the patched version.

My host interfaces are: docker0, eth0-1, lo, vboxnet0-2. Doesn't work on other machines I have with enp0s25, wlp4s0 either.

[ageis]

Ok, tried manually returning eth0 or vboxnet2 for ifaces and that still didn't work. I eventually figured out that the problem was with the IP I was specifying: 10.0.2.2. This is a common IP used by VirtualBox VMs, and the third-party code I'm trying to automate absolutely depends upon it. But why is it not available to Vagrant? It seems to be happy with 10.0.2.15 instead, but that's not the IP I want.

Does anyone know how I could make that IP address work with my Vagrant machine and VirtualBox? If you attempt to set it manually to 10.0.2.2 with ifconfig or ip within the VM or in /etc/network/interfaces, that command just hangs forever.

[chrisroberts]

@karlkfi Thanks for confirming #7866 does fix the problem!

[karlkfi]

Update: my example config had auto_config:false, but that actually works fine. The problem only occurs with auto_config:true (default).

As for 10.0.2.2, make sure you have a host-only network created in vbox that covers that IP.

[rherrick]

I've been having a similar issue but it manifests differently. We have a fairly complicated Vagrant configuration that sets the VM IP address with the config.vm.network setting:

config.vm.network 'private_network', ip: profile['vm_ip']

On 1.8.5 we have no issues. This results in /etc/network/interfaces like this:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp
pre-up sleep 2
\#VAGRANT-BEGIN
\# The contents below are automatically generated by Vagrant. Do not modify.
auto eth1
iface eth1 inet static
      address 10.1.1.170
      netmask 255.255.255.0
\#VAGRANT-END

With 1.8.6, I don't see the command hanging: everything configures and starts up properly, but you just can't reach the VM at the specified IP address. /etc/network/interfaces looks like this:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp
pre-up sleep 2
\#VAGRANT-BEGIN
\# The contents below are automatically generated by Vagrant. Do not modify.
auto eth0
iface eth0 inet static
      address 10.1.1.170
      netmask 255.255.255.0
\#VAGRANT-END

Note that eth0 is defined twice. If I modify the file and change the second eth0 def to eth1, I can reboot (I thought sudo ifup eth1 worked, but, while it does bring up eth1 on the VM, nothing outside recognizes the routing to that IP, so the reboot is required before we can access the VM by the configured IP) and things are fine.

The other weird thing is that this behavior is inconsistent. While attempting to check on using ifup, I kept creating VMs that worked just fine: the interfaces definition still had two entries for eth0, but apparently the networking service realized this and assigned the second definition to eth1. In other cases, I'll only have eth0 defined.

This happens pretty much the same way on both OS X and Linux Mint.

I can confirm that the monkey-patch procedure described by @karlkfi works to fix the problem: running with that results in both eth0 and eth1 being properly defined, without requiring any changes to the interfaces configuration.

Let me know if you have any other questions about our configuration or environment.

[ageis]

I still can't set a custom eth0 IP address for my VM. I want to give it 10.0.3.2, for example, either via private_network or public_network, either way, and it always comes up with 10.0.2.15. I don't understand why this basic functionality doesn't work...

[archdesigner]

now i'v got same bug.but when i start vagrant.
i put down my usb network adapter
it's work!
sorry for bad english

on Mac os 10.12.6 Virtual Box 5.1.24 vagrant 2.0

[queglay]

I also get a hang here -

Configuring and enabling network interfaces

as soon as I start using this line -

config.vm.network "public_network"

And I specify to bridge to the wifi on a macbook pro on a network I'm currently on. everything was fine wired over ethernet on another network 2 days ago.

I've destroyed the instance many times and on vagrant up the hang occurs.

[queglay]

I couldn't use vagrant to spin up (a once already working vm) that was used in production with similar symptoms today. it looks like the cause this time was different - the NIC that was specified in the .Vagrantfile was unavailable. It would be great if there was enough verbosity to see the cause to make it apparent - as a suggestion.

[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.