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

Question

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

dddpaul opened this issue 8 years ago · 18 comments

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.

Answer 1 · 2017-01-03T12:57:51.000Z

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

Answer 2 · 2017-01-03T13:09:19.000Z

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

Answer 3 · 2017-01-03T13:14:31.000Z

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

Answer 4 · 2017-01-04T16:02:49.000Z

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

Answer 5 · 2017-01-04T22:10:50.000Z

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

Answer 6 · 2017-01-06T09:47:03.000Z

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.

Answer 7 · 2017-01-06T18:31:54.000Z

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

Answer 8 · 2017-01-08T02:41:36.000Z

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.

Answer 9 · 2017-01-09T16:32:28.000Z

Fixed via #8148. Thanks for the report!

Answer 10 · 2017-01-09T16:34:12.000Z

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

Answer 11 · 2017-01-29T13:02:36.000Z

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

Answer 12 · 2017-01-29T17:11:01.000Z

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

Answer 13 · 2017-02-23T00:32:54.000Z

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

Having the same issue.

Answer 14 · 2017-03-21T14:13:56.000Z

@chrisroberts The issue persists, please reopen this issue.

Answer 15 · 2017-07-17T13:38:38.000Z

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.

Answer 16 · 2017-07-26T12:35:27.000Z

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.

Answer 17 · 2017-10-11T17:36:36.000Z

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.

Answer 18 · 2020-03-31T02:23:29.000Z

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.