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

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

Closed
dddpaul opened this Issue Jan 2, 2017 · 17 comments

Comments

Projects
None yet
@dddpaul

dddpaul commented Jan 2, 2017

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:

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

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

@jairojunior

This comment has been minimized.

Show comment
Hide comment
@jairojunior

jairojunior Jan 3, 2017

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 commented Jan 3, 2017

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

This comment has been minimized.

Show comment
Hide comment
@jairojunior

jairojunior Jan 3, 2017

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

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

@jairojunior

This comment has been minimized.

Show comment
Hide comment
@jairojunior

jairojunior Jan 3, 2017

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

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

@bwlz

This comment has been minimized.

Show comment
Hide comment
@bwlz

bwlz Jan 4, 2017

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

bwlz commented Jan 4, 2017

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

This comment has been minimized.

Show comment
Hide comment
@hardyjohnson

hardyjohnson Jan 4, 2017

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

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

@sapientpants

This comment has been minimized.

Show comment
Hide comment
@sapientpants

sapientpants Jan 6, 2017

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 commented Jan 6, 2017

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

This comment has been minimized.

Show comment
Hide comment
@sapientpants

sapientpants Jan 6, 2017

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

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

@neilbryson

This comment has been minimized.

Show comment
Hide comment
@neilbryson

neilbryson Jan 8, 2017

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.

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.

@utdrmac utdrmac referenced this issue in grypyrg/vagrant-percona Jan 9, 2017

Closed

No custom IPs work with vitrualbox #26

@chrisroberts

This comment has been minimized.

Show comment
Hide comment
@chrisroberts

chrisroberts Jan 9, 2017

Collaborator

Fixed via #8148. Thanks for the report!

Collaborator

chrisroberts commented Jan 9, 2017

Fixed via #8148. Thanks for the report!

@utdrmac

This comment has been minimized.

Show comment
Hide comment
@utdrmac

utdrmac Jan 9, 2017

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

utdrmac commented Jan 9, 2017

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

This comment has been minimized.

Show comment
Hide comment
@pipisco

pipisco Jan 29, 2017

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

pipisco commented Jan 29, 2017

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

This comment has been minimized.

Show comment
Hide comment
@utdrmac

utdrmac Jan 29, 2017

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

utdrmac commented Jan 29, 2017

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

@retr0h retr0h referenced this issue in kubernetes-incubator/kubespray Feb 23, 2017

Closed

Ensure eth1 comes up #1039

@retr0h

This comment has been minimized.

Show comment
Hide comment
@retr0h

retr0h Feb 23, 2017

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

Having the same issue.

retr0h commented Feb 23, 2017

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

Having the same issue.

@agusti-t

This comment has been minimized.

Show comment
Hide comment
@agusti-t

agusti-t Mar 21, 2017

@chrisroberts The issue persists, please reopen this issue.

@chrisroberts The issue persists, please reopen this issue.

@kanaifu

This comment has been minimized.

Show comment
Hide comment
@kanaifu

kanaifu Jul 17, 2017

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.

kanaifu commented Jul 17, 2017

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

This comment has been minimized.

Show comment
Hide comment
@emielmolenaar

emielmolenaar Jul 26, 2017

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.

emielmolenaar commented Jul 26, 2017

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.

@bertjwregeer

This comment has been minimized.

Show comment
Hide comment
@bertjwregeer

bertjwregeer Oct 11, 2017

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.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment