Vagrant 1.9.1 private networking configures unreachable VirtualBox VM

[Nezteb]

Vagrant version

1.9.1

Using VirtualBox 5.1.10.
Using plugin vagrant-hostsupdater (1.0.2)

Host operating system

Windows 10
Mac OS X 10.11

Guest operating system

CentOS 7.2

Running nginx

Vagrantfile

We're using KitchenCI along with Chef.

Our .kitchen.yml config generates this Vagrantfile:

Vagrant.configure("2") do |c|
  c.berkshelf.enabled = false if Vagrant.has_plugin?("vagrant-berkshelf")
  c.vm.box = "bento/centos-7.2"
  c.vm.hostname = "tools-dev.mycompany.com"
  c.vm.network(:forwarded_port, {:guest=>80, :host=>80})
  c.vm.network(:forwarded_port, {:guest=>443, :host=>443})
  c.vm.network(:private_network, {:ip=>"172.28.128.138"})
  c.vm.synced_folder ".", "/vagrant", disabled: true
  c.vm.provider :virtualbox do |p|
  end
end

Debug output

None of the tools involved give any error output. All tests pass, nginx is running on the right ports. Verified that VirtualBox networking is configured correctly by Vagrant.

Expected behavior

Should be able to visit tools-dev.mycompany.com in the host browser and get a 404 nginx page.

Actual behavior

Can't reach tools-dev.mycompany.com or 172.28.128.138.

If we kitchen login (which is the equivalent of vagrant ssh) into the box and run curl localhost we get the expected HTML dump, but somehow VirtualBox networking isn't working. Same results on two different host machines (Windows & Mac).

To get around this (temporarily) we had to set up the above port forwards. Then we can just navigate to localhost:80 and receive the expected 404 page.

Reason for submitting issue: Reverting to Vagrant 1.8.7 (and changing nothing else) gives expected behavior.

Steps to reproduce

1. Install the above versions of VirtualBox, Vagrant, and whatever provisioners you like.
2. Set up VM with private networking.
3. Configure nginx web server and verify it's listening.
4. Use vagrant-hostsupdater or edit your hosts file manually.
5. Visit hostname in browser.

References

I searched through other issues and didn't find anything that matched this issue. This was the closest one I could find, but our CentOS guest does get an IPv4 address: #8096

[Dispader]

@Nezteb I just started observing this myself (according to GitHub, you beat me to the bug report by 2m). For you, is this limited to CentOS/RedHat/Fedora?

[Nezteb]

@Dispader Just tried it on Ubuntu 16.04 and the nginx page works as expected. I had not previously tried it on Ubuntu, as this project requires CentOS.

So the issue does seem to be confined to CentOS. Ubuntu works fine. As mentioned in the semi-related issue I linked earlier, I'm willing to bet this NetworkManager config is part of the problem.

[karlkfi]

I'm also seeing this bug on Vagrant 1.9.1 (but not Vagrant 1.9.0) using a guest CentOS 7.2 VM on VirtualBox 5.1.10.

The symptom seems to be that the hostonly inet is completely missing when you run ifconfig. There's a enp0s3 from dhcp, but no enp0s8 with the hostonly IP.

Based on that, it sound related to this #7876 (a 1.8.6 bug) which was fixed by #7866. That makes me think that it was caused by recent changes to https://github.com/mitchellh/vagrant/blob/master/plugins/guests/linux/cap/network_interfaces.rb made in 5482692

[karlkfi]

Monkey patching to revert 5482692 does not fix the problem. So that's not the issue.

[karlkfi]

Confirmed that enp0s8 comes back if you sudo /etc/init.d/network restart as recommended in #8096 (comment)

[karlkfi]

Executing sudo service network restart also fixes the issue, but sudo service NetworkManager restart does not, because enp0s8 is not managed by NetworkManager (NM_CONTROLLED=no).

So the problem is the same as #8096 and is caused by the change in #8052.

[karlkfi]

Verified that #8052 is the problem. Reverting it with a monkey patch causes my VMs to come up with both enp0s3 and enp0s8.

[Nezteb]

@karlkfi As mentioned in this comment on #8052, I think the solution will involve allowing an argument for NM_CONTROLLED in network_static.erb when CentOS 7 or RHEL 7 are used.

[karlkfi]

Do you actually want the host-only static interface to be NetworkManager controlled? What if there are other interfaces that aren't?

[Nezteb]

Good point. I saw your comment here and agree with you. Perhaps running /etc/init.d/network restart or bringing the interface down and then up would have a different result. I'll try it out tomorrow with Fedora and CentOS again.

[sirn]

I'm also affected by this. I'm currently using CentOS 7.1 with NFS mount and got this error while Vagrant trying to mount NFS shared folders (posting the error just in case anyone else is having the same problem):

==> interfaces: Mounting NFS shared folders...
The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!

mount -o vers=3,udp 192.168.196.1:/Users/sirn/Projects/app /vagrant
result=$?
if test $result -eq 0; then
if test -x /sbin/initctl && command -v /sbin/init && /sbin/init 2>/dev/null --version | grep upstart; then
/sbin/initctl emit --no-wait vagrant-mounted MOUNTPOINT=/vagrant
fi
else
exit $result
fi


Stdout from the command:



Stderr from the command:

mount.nfs: access denied by server while mounting 192.168.196.1:/Users/sirn/Projects/app

Manually reverting the #8052 mentioned in the above comment in local installation make everything works again.

[chrisroberts]

Closing as dup of #8096

[ghost]

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.