Vagrant: How can I configure Vagrant to set `NM_CONTROLLED` to `yes` value ?

Created on 4 Feb 2016  ยท  8Comments  ยท  Source: hashicorp/vagrant

I use Vagrant + Centos 7.2

I've a bug with NM_CONTROLLED=no in /etc/sysconfig/network-scripts/ifcfg-eth0

How can I configure Vagrant to set NM_CONTROLLED to yes value ?

Context : http://lists.openshift.redhat.com/openshift-archives/users/2016-February/msg00006.html

guesredhat

Most helpful comment

@sethvargo This is in fact a bug. Vagrant is setting NM_CONTROLLED=no in the ifcfg-file but then expecting NetManager to bring up the interface.

Here's the snippet from vagrant --debug up where it does an nmcli reload rather than an ifup:

 INFO ssh: Execute: # Down the interface before munging the config file. This might
# fail if the interface is not actually set up yet so ignore
# errors.
/sbin/ifdown 'eth1'
# Move new config into place
mv -f '/tmp/vagrant-network-entry-eth1-1484516591-0' '/etc/sysconfig/network-scripts/ifcfg-eth1'
# attempt to force network manager to reload configurations
nmcli c reload || true

# Restart network (through NetworkManager if running)
if service NetworkManager status 2>&1 | grep -q running; then
  service NetworkManager restart
else
  service network restart
fi
 (sudo=true)
DEBUG ssh: stderr: usage: ifdown <configuration>

DEBUG ssh: stderr: Redirecting to /bin/systemctl restart  NetworkManager.service

And here's the content of ifcfg-eth1:

$ 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.1.50
NETMASK=255.255.255.0
DEVICE=eth1
PEERDNS=no
#VAGRANT-END

So of course restarting network manager does nothing.

Workaround is to use a shell provisioner or whatever to do a ifup eth1.

This "broke" within the last 12 months or so as I previously had this working and then when I returned to work with it today was stuck on it not working -- after I had updated to Vagrant 1.9.1 and Virtuabox 5.1.10r112026.

All 8 comments

Hi @harobed

We like to reserve the issue tracker for bug reports and feature requests. For usage questions, can you please use the Vagrant mailing list: https://groups.google.com/forum/#!forum/vagrant-up. Thanks!

@sethvargo This is in fact a bug. Vagrant is setting NM_CONTROLLED=no in the ifcfg-file but then expecting NetManager to bring up the interface.

Here's the snippet from vagrant --debug up where it does an nmcli reload rather than an ifup:

 INFO ssh: Execute: # Down the interface before munging the config file. This might
# fail if the interface is not actually set up yet so ignore
# errors.
/sbin/ifdown 'eth1'
# Move new config into place
mv -f '/tmp/vagrant-network-entry-eth1-1484516591-0' '/etc/sysconfig/network-scripts/ifcfg-eth1'
# attempt to force network manager to reload configurations
nmcli c reload || true

# Restart network (through NetworkManager if running)
if service NetworkManager status 2>&1 | grep -q running; then
  service NetworkManager restart
else
  service network restart
fi
 (sudo=true)
DEBUG ssh: stderr: usage: ifdown <configuration>

DEBUG ssh: stderr: Redirecting to /bin/systemctl restart  NetworkManager.service

And here's the content of ifcfg-eth1:

$ 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.1.50
NETMASK=255.255.255.0
DEVICE=eth1
PEERDNS=no
#VAGRANT-END

So of course restarting network manager does nothing.

Workaround is to use a shell provisioner or whatever to do a ifup eth1.

This "broke" within the last 12 months or so as I previously had this working and then when I returned to work with it today was stuck on it not working -- after I had updated to Vagrant 1.9.1 and Virtuabox 5.1.10r112026.

I have the same issue with Fedora 25 and vagrant 1.9.1

This is definitely a bug.

This has become very visible recently with Virtualbox 5.1 and Vagrant 1.9.1 on macOS. It does affect our plugin, in the meantime we are working around it with a shell provisioner.

@harobed can you test with latest version of Vagrant?

This should be fixed already

Ok, I'm going to test itโ€ฆ Thanks

I can verify this does, in fact, work!

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.

Was this page helpful?
0 / 5 - 0 ratings