private_network interface stays in "down" state on "vagrant up" #8166

dddpaul · 2017-01-02T08:04:37Z

Hello.

Private network interface stays in "down" state without assigned IP address with Vagrant 1.9.1, VirtualBox 5.1.10 on MacOS Sierra (10.12.2) and Ubuntu 16.04 with Centos 7.3 (centos/7 box).

Box network settings in Vagrantfile:

node.vm.box = "centos/7"
node.vm.network :private_network, ip: "192.168.40.111"

Network configuration inside box:

cat /etc/sysconfig/network-scripts/ifcfg-eth1
#VAGRANT-BEGIN
# The contents below are automatically generated by Vagrant. Do not modify.
NM_CONTROLLED=no
BOOTPROTO=none
ONBOOT=yes
IPADDR=192.168.40.111
NETMASK=255.255.255.0
DEVICE=eth1
PEERDNS=no
#VAGRANT-END

But eth1 is in down state actually:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 52:54:00:22:5b:53 brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic eth0
       valid_lft 85838sec preferred_lft 85838sec
    inet6 fe80::5054:ff:fe22:5b53/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
    link/ether 08:00:27:31:b1:bd brd ff:ff:ff:ff:ff:ff

There are couple of workarounds:

Restart network service while provisioning. For example (for Ansible):

- name: ensure all interfaces are up 
  service: name=network enabled=yes state=restarted

The downside - provision has no effect when box is restarted by reboot command or vagrant reload.

Bring interface up in /etc/rc.local:

/sbin/ifup eth1

The downside - interface name may be changed sometimes by udev etc.

PS: I posted this text as a comment to #5590 because symptoms are quite similar. Then there was a bunch of comments from other people complaining about this problem with Vagrant 1.9.1 on different systems. They say mostly that downgrade to 1.8.7 solves the problem. So I've decided to start up a new issue.

The text was updated successfully, but these errors were encountered:

jairojunior · 2017-01-03T12:57:51Z

Decided to investigate this and I'm very suspicious of plugins/guests/redhat/cap/configure_networks.rb and plugins/guests/redhat/cap/change_host_name.rb

network service used to be restarted unconditionally, but it checks for NetworkManager instead in 191.

Not my area of expertise, but I'll try to fix locally.

v1.9.0...v1.9.1

PS: It works with v1.9.0

jairojunior · 2017-01-03T13:09:19Z

Just confirmed that rolling back to service network restart in plugins/guests/redhat/cap/configure_networks.rb fixes the problem.

jairojunior · 2017-01-03T13:14:31Z

It seems to already have an open PR for this: #8148

ghost · 2017-01-04T16:02:49Z

Sounds like a fix is about squared away, but I'm seeing this as well in Vagrant 1.9.1 with Virtualbox 5.1.10_Debian r112026 and the box 'geerlingguy/centos7'. The issue does not manifest with the VMware provider.

My current workaround:

vm.provision "shell",
  inline: "sudo ifup [affected interface]"

hardyjohnson · 2017-01-04T22:10:50Z

@bwlz just a warning you may run into issues with subsequent boots as provision shell will only run on provision.

sapientpants · 2017-01-06T09:47:03Z

I'm experiencing this problem as well.

On vagrant up I see the following in /var/log/messages

Jan  6 09:17:31 localhost NetworkManager[4207]: <info>  [1483694251.4576] ifcfg-rh: new connection /etc/sysconfig/network-scripts/ifcfg-eth1 (9c92fad9-6ecb-3e6c-eb4d-8a47c6f50c04,"System eth1")
Jan  6 09:17:31 localhost NetworkManager[4207]: <info>  [1483694251.4576] ifcfg-rh: Ignoring connection /etc/sysconfig/network-scripts/ifcfg-eth1 (9c92fad9-6ecb-3e6c-eb4d-8a47c6f50c04,"System eth1") due to NM_CONTROLLED=no. Unmanaged: interface-name:eth1.

I wonder if generating the ifcfg-eth1 file with NM_CONTROLLED=yes would sort this out for using the NetworkManager to bring up the network interfaces.

Issuing service network restart brings up the private interface although the following shows up in /var/log/messages

Jan  6 09:25:04 localhost firewalld: ERROR: Failed to load '/etc/sysconfig/network-scripts/ifcfg-eth1': [Errno 13] Permission denied: '/etc/sysconfig/network-scripts/ifcfg-eth1'
Jan  6 09:25:04 localhost firewalld: ERROR: Calling post func <function ifcfg_set_zone_of_interface at 0x7f0fa088d7d0>(('', 'eth1')) failed: [Errno 13] Permission denied: '/etc/sysconfig/network-scripts/ifcfg-eth1'

Looking at /etc/sysconfig/network-scripts/ifcfg-* the permissions are as follows:

-rw-r--r--. 1 root    root    254 Sep 12 10:47 /etc/sysconfig/network-scripts/ifcfg-lo
-rw-r--r--. 1 root    root     86 Dec 15 11:14 /etc/sysconfig/network-scripts/ifcfg-eth0
-rw-------. 1 vagrant vagrant 213 Jan  6 09:17 /etc/sysconfig/network-scripts/ifcfg-eth1

Not sure if the latter should be a separate issue or not.

sapientpants · 2017-01-06T18:31:54Z

The NM_CONTROLLED=yes or commented out seems to do the trick for me for the network to come up.

neilbryson · 2017-01-08T02:41:36Z

The private network of my Oracle Linux Vagrant box just randomly stopped working on v1.9.1. It was alright a few days ago but it just decided to stop working. Restarting the network service brings up the private network interface but I still cannot connect into it from my host machine.

Can confirm this issue does not occur when I downgraded to v1.8.7.

chrisroberts · 2017-01-09T16:32:28Z

Fixed via #8148. Thanks for the report!

utdrmac · 2017-01-09T16:34:12Z

Same experience. I have the following configured:
node_config.vm.network :private_network, ip: local_vm_ip, adaptor: 2

eth0 comes up fine with 10.0.2.15. eth1 is configured under /etc/sysconfig/.../ifcfg-eth1 with the proper IP, but it does not start when system boots.

Virtualbox 5.1.12
Vagrant 1.9.1
MacOS 10.12.2
CentOs 7.3.1611

pipisco · 2017-01-29T13:02:36Z

Same experience. Private interface (eth1) cannot auto start after
vagrant up

My configuration.
MacOS: 10.10.5
CentOS: centos/7 (virtualbox, 1611.01)
Vagrant 1.9.1
VBox: 5.1.12r112440

utdrmac · 2017-01-29T17:11:01Z

@chrisroberts please re-open this. The fix is not working for many still.

retr0h · 2017-02-23T00:32:54Z

@chrisroberts please re-open this. The fix is not working for many still.

Having the same issue.

agusti-t · 2017-03-21T14:13:56Z

@chrisroberts The issue persists, please reopen this issue.

ghost · 2017-07-17T13:38:38Z

Vagrant 1.9.7
Virtualbox 5.1.22 r115126
HOST: CentOS Linux release 7.3.1611
Box: CentOS Linux release 7.3.1611

Issue persists.

emielmolenaar · 2017-07-26T12:35:27Z

Issue still present here on Ubuntu 16.04, Vagrant 1.9.7 and Virtualbox 5.1.24. A manual sudo ifconfig vboxnet0 up workarounds the issue for now but it is pretty annoying.

digitalresistor · 2017-10-11T17:36:36Z

Is there a way to configure the interface without NM_CONTROLLED=no being added? RHEL has gone all-in on NetworkManager and while the original "network service" still exists to bring up interface it has been heavily deprecated, and letting NetworkManager manage the interface is a much better solution.

ghost · 2020-03-31T02:23:29Z

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.

jairojunior mentioned this issue Jan 3, 2017

Revert "Fix service network restart on RHEL-7 / Fedora" #8148

Merged

utdrmac mentioned this issue Jan 9, 2017

No custom IPs work with vitrualbox grypyrg/vagrant-percona#26

Closed

chrisroberts closed this as completed Jan 9, 2017

kikitux mentioned this issue Jan 16, 2017

Second network interface down on vagrant up #8206

Closed

retr0h mentioned this issue Feb 23, 2017

Ensure eth1 comes up kubernetes-sigs/kubespray#1039

Closed

blackillzone mentioned this issue May 23, 2017

IP of a Vagrantbox unreacheable after adding it in the molecule.yml ansible/molecule#839

Closed

cfebs mentioned this issue Jul 21, 2017

Running vagrant up hangs on NFS mounting (Vagrant 1.4.3) wunki/vagrant-freebsd#4

Closed

MBetters mentioned this issue Oct 18, 2017

eth Interface Fails to Restart #9069

Closed

ghost locked and limited conversation to collaborators Mar 31, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

private_network interface stays in "down" state on "vagrant up" #8166

private_network interface stays in "down" state on "vagrant up" #8166

dddpaul commented Jan 2, 2017

jairojunior commented Jan 3, 2017 •

edited

Loading

jairojunior commented Jan 3, 2017

jairojunior commented Jan 3, 2017

ghost commented Jan 4, 2017 •

edited by ghost

Loading

hardyjohnson commented Jan 4, 2017

sapientpants commented Jan 6, 2017 •

edited

Loading

sapientpants commented Jan 6, 2017

neilbryson commented Jan 8, 2017

chrisroberts commented Jan 9, 2017

utdrmac commented Jan 9, 2017

pipisco commented Jan 29, 2017

utdrmac commented Jan 29, 2017

retr0h commented Feb 23, 2017

agusti-t commented Mar 21, 2017

ghost commented Jul 17, 2017

emielmolenaar commented Jul 26, 2017 •

edited

Loading

digitalresistor commented Oct 11, 2017

ghost commented Mar 31, 2020

private_network interface stays in "down" state on "vagrant up" #8166

private_network interface stays in "down" state on "vagrant up" #8166

Comments

dddpaul commented Jan 2, 2017

jairojunior commented Jan 3, 2017 • edited Loading

jairojunior commented Jan 3, 2017

jairojunior commented Jan 3, 2017

ghost commented Jan 4, 2017 • edited by ghost Loading

hardyjohnson commented Jan 4, 2017

sapientpants commented Jan 6, 2017 • edited Loading

sapientpants commented Jan 6, 2017

neilbryson commented Jan 8, 2017

chrisroberts commented Jan 9, 2017

utdrmac commented Jan 9, 2017

pipisco commented Jan 29, 2017

utdrmac commented Jan 29, 2017

retr0h commented Feb 23, 2017

agusti-t commented Mar 21, 2017

ghost commented Jul 17, 2017

emielmolenaar commented Jul 26, 2017 • edited Loading

digitalresistor commented Oct 11, 2017

ghost commented Mar 31, 2020

jairojunior commented Jan 3, 2017 •

edited

Loading

ghost commented Jan 4, 2017 •

edited by ghost

Loading

sapientpants commented Jan 6, 2017 •

edited

Loading

emielmolenaar commented Jul 26, 2017 •

edited

Loading