-
Notifications
You must be signed in to change notification settings - Fork 4.4k
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 comes up with no IPv4 address without manual restart #8096
Comments
I am seeing a very similar behavior on a CentOS VM (running on macOS). This behavior is happening in Vagrant 1.9.1 and NOT 1.9.0. This manifests itself in a failure to mount our defined synced folders between host and VM because the hostonly interface doesn't come up. Vagrantfile
Startup output
If I SSH into the machine, the hostonly interface doesn't have an IP assigned:
The IP address is configured:
My issue differs from @rupert654 in that halting and starting the VM doesn't fix the issue. However, I can restart networking and the interface will come back up. If I ssh into the VM while the shared folders are being mounted and restart networking, the procedure will succeed.
|
I was having this issue too from |
I think this is a regression in #8052. I reverted these changes in my local 1.9.1 installation and it is working again. Can anyone else confirm? |
@andyshinn I tried this out (built vagrant and reverse patched it on master) and all went good. I'm going to try without the reverse patch too. |
Yup, you've found the regression for sure. Undoing the patch pumps out that error. |
I've hit this too—confirmed when I ran my automated build/test cycle for my I just ran:
And I get the error when it tries mounting the NFS share:
This was on macOS Sierra 10.12.1, using Vagrant 1.9.1 and Packer 0.12.0. |
@chrisroberts for this one, the command being submitted on RH7/Centos7 is:
The problem is on this line:
Since so, when RedHat7/Centos7 is used, should be:
So this template should take an argument for
|
@kikitux Thanks a lot, I confirm that your fix sets every thing back on track, it's working fine. |
As workaround, in the meantime this gets fixed, you can use: replace IFACE with eth1/ens34/name_of_interface config.vm.provision "shell", inline: "ifup IFACE", run: "always" |
I'm not sure that changing It's not clear why #8052 was made yet, because the PR doesn't actually say precisely what problem it's fixing. It says " I think it comes down to this:
What are the pros and cons of each approach? Why choose one over the other? |
Is it a problem that vagrant 1.9.1 is not setting the correct labels on the ifcfg-* file it creates for the private nic it adds? I am seeing error in audit2allow and the selinux labels (as well as file owner and permissions) on the ifcfg-eth1 file are messed up. Centos 7.3 I am defining nic in vagrant file like so: Notice ifcfg-eth1 labels, etc: I can fix permissions, ownership and run chcon to fix labels but they get changed back on restart. Restarting the network service seems to bring up the interface but might as well fix the labels. |
@karlkfi maybe just enable NM_CONTROLLED inline? # Restart network (through NetworkManager if running)
if service NetworkManager status 2>&1 | grep -q running; then
sed -e 's/^NM_CONTROLLED=no/NM_CONTROLLED=yes/g' /etc/sysconfig/network-scripts/ifcfg-*
service NetworkManager restart
else
service network restart
fi I would guess a large amount of RHEL-like vagrant machines will be running NetworkManager out of the box, but if they wish to change that it should be up to the end-user to implement any non-standard behavior either in a provision script or by creating a file via the kickstart config like so: # ifcfg-eth0
cat > /etc/sysconfig/network-scripts/ifcfg-eth0 <<-EOT
DEVICE=eth0
ONBOOT=yes
BOOTPROTO=dhcp
TYPE=Ethernet
EOT FWIW in our packer builds we also include Summary : NetworkManager config file for "server-like" defaults
Description :
This adds a NetworkManager configuration file to make it behave more
like the old "network" service. In particular, it stops NetworkManager
from automatically running DHCP on unconfigured ethernet devices, and
allows connections with static IP addresses to be brought up even on
ethernet devices with no carrier.
This package is intended to be installed by default for server
deployments. |
Good to know about As for enabling |
@karlkfi I believe the default/only solution should just be to restart the network service and let the system take the appropriate action based on how it's configured, ie: if it should restart NetworkManger.service or something else like systemd-networkd.service. |
@tonylambiris: That's what it used to do. If that worked everywhere, it wouldn't have been changed in the first place. |
Just for the sake of more information: same issues for me on CentOS7 with Vagrant 1.9.1 |
@karlkfi For me running |
I've been using |
If you're like me and using @jerrywardlow's workaround but get errors during the |
Restarting the entire network subsystem just feels super heavy-handed, especially considering some interfaces could be configured manually/externally (ie: using flanneld or creating a bridge interface). Vagrant should only operate in the interface definition and not make assumptions globally. Could one of the project admins please explain why the
|
@tonylambiris good point. I think this is the best way to work. |
I think you can't use I believe that the best thing to do is to bring up only that interface which need to be up I downgraded to 1.9.0 which don't have this 1.9.1 behavior. |
My workaround here, until a permanent fix:
|
This is fixed in the 1.9.2 release via PR #8148. Thanks! |
So what happens when distros start migrating to systemd-networkd as their network manager? |
I am seeing this behaviour in 1.9.5 |
Seeing this behavior as well with Vagrant 1.9.3 and fedora 25. |
Same for me as 1.9.5 , scientific linux 6.1, host MacOS Sierra. getting eth0 and eth2 both assigned 192.168.10.10 |
@ruibinghao @ianmiell @nezaboravi Can you test vagrant v1.9.2 ? https://releases.hashicorp.com/vagrant/1.9.2/ @tonylambiris |
let me find first how to uninstall the current one and will give a try to 1.9.2 |
FWIW, this is still happening for me on Vagrant 1.9.8, using a box that has CentOS 7.0 (base box: https://app.vagrantup.com/peichman-umd/boxes/ruby/versions/1.0.0). |
I ran into a few of the bugs regarding CentOS 7, systemd and Vagrant 1.9+. I had an issue with setting private networking would bring up some random subnet, remove the Vagrant host ip (10.0.2.15) and be completely unavailable on the network. When checking the interfaces, I would see, lo, eth0, eth1, and enp0s8. I resolved this issue by rebuilding my images to use the following in the kickstart:
Added additional systemd network package: You can also manually modify the /etc/default/grub and rebuild the initrd. I tested this and found it working on Vagrant 2.0. |
@ecray Is your assessment of this bug that the problem is in the base box and not the Vagrant code? |
I always blame SystemD. But, it seems like Vagrant is not detecting if it should use persistent device naming as it creates eth0, but also enp0s8 when specifying a private network. |
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. |
Vagrant version
I'm running Vagrant 1.8.6. This is not the latest version but I can't run 1.8.7 due to #8024 , nor 1.90 due to #8088 .
Host operating system
Windows 7
Guest operating system
CentOS 7
Vagrantfile
Expected behavior
Each VM should have assigned the IP addresses specified in the Vagrantfile.
Actual behavior
No IP address appears to be assigned. However, an IP address is assigned after restarting.
Steps to reproduce
Log into one of the nodes
vagrant ssh master
Verify that the IP address is actually being configured
References
It seems very similar to #2968. However, that has been fixed in a previous version.
The text was updated successfully, but these errors were encountered: