Vagrant: Continuing to experience problems with port forwarding using VMWare Fusion provider for Vagrant

[jakewan]

As requested by @chrisroberts in the ticket referenced at the bottom, I'm opening a new ticket to track ongoing progress on this issue. The problem is intermittent, so it shouldn't be surprising if you follow the "steps to reproduce" and nothing weird happens. But eventually it happens, and then you can be stuck in that state for quite awhile until the problem mysteriously corrects itself (or we can identify a reliable workaround).

_Please note that Virtualbox is not installed._

Vagrant version

$ vagrant -v
Vagrant 1.9.4

$ vagrant plugin list
vagrant-share (1.1.7)
  - Version Constraint: > 0
vagrant-vmware-fusion (4.0.19)
  - Version Constraint: > 0

Host operating system

macOS Sierra
10.12.4

Guest operating system

See Vagrantfile

Vagrantfile

Vagrant.configure("2") do |config|
  config.vm.box = "hashicorp/precise64"
  config.vm.network "forwarded_port", guest: 80, host: 8080
end

Debug output

https://gist.github.com/jakewan/2a0b51a542c19b9bdc3ea83b070dd00c

Expected behavior

Given a nat.conf file with no uncommented entries in the [incomingtcp] section, upon running vagrant up:

• VMWare Fusion VM should start with host ports 8080 and 2_nnn_ forwarded to guest ports 80 and 22 respectively.
• There should be two entries in nat.conf representing those port forwarding settings surrounded by VAGRANT comments.

Actual behavior

An error like this is shown:

Vagrant cannot forward the specified ports on this VM, since they
would collide with some other application that is already listening
on these ports. The forwarded port to 8080 is already in use
on the host machine.

To fix this, modify your current project's Vagrantfile to use another
port. Example, where '1234' would be replaced by a unique host port:

  config.vm.network :forwarded_port, guest: 80, host: 1234

Sometimes, Vagrant will attempt to auto-correct this for you. In this
case, Vagrant was unable to. This is usually because the guest machine
is in a state which doesn't allow modifying port forwarding. You could
try 'vagrant reload' (equivalent of running a halt followed by an up)
so vagrant can attempt to auto-correct this upon booting. Be warned
that any unsaved work might be lost.

nat.conf contains unmanaged entries like these:

# Use these with care - anyone can enter into your VM through these...
# The format and example are as follows:
#<external port number> = <VM's IP address>:<VM's port number>
#8080 = 172.16.3.128:80
8081 = 192.168.223.172:80
2222 = 192.168.223.172:22
8080 = 192.168.223.173:80
2200 = 192.168.223.173:22

Steps to reproduce

1. Open /Library/Preferences/VMware\ Fusion/vmnet8/nat.conf and delete any entires in the [incomingtcp] section.
2. vagrant up

If nothing happens here, try doing vagrant halt -> vagrant up a few times.

If that doesn't work, try doing vagrant destroy -> vagrant up.

If that doesn't work, try working with another Vagrant-managed VMWare VM for a while and come back. Eventually it happens.

References

• https://github.com/mitchellh/vagrant/issues/7948

[jakewan]

Attaching my logs from the up-halt-up sequence:

• vagrant.1-vagrant-up.log
• vagrant.2-vagrant-halt.log
• vagrant.3-vagrant-up.log

Looking back over the comments on the original issue, when we get into this state, people were having success cleaning out port-forwarding entries in both files:

• /Library/Preferences/VMware\ Fusion/vmnet8/nat.conf
• /Library/Preferences/VMware\ Fusion/networking

I can confirm that this does seem to be a consistent workaround to get vagrant up to work again. I was able to go through this sequence 5 times with exactly the same result.

Reference:

https://github.com/mitchellh/vagrant/issues/7948#issuecomment-261734662

[chrisroberts]

@jakewan Are the three log files from three consecutive runs with no other vagrant runs in other directories?

[jakewan]

Yes. Here were the commands:

manzanita:vmware-test jacob$ vagrant up --debug &> vagrant.1-vagrant-up.log
manzanita:vmware-test jacob$ vagrant status
Current machine states:

default                   running (vmware_fusion)

The VM is running. To stop this VM, you can run `vagrant halt` to
shut it down, or you can run `vagrant suspend` to simply suspend
the virtual machine. In either case, to restart it again, run
`vagrant up`.
manzanita:vmware-test jacob$ vagrant halt --debug &> vagrant.2-vagrant-halt.log
manzanita:vmware-test jacob$ vagrant status
Current machine states:

default                   not running (vmware_fusion)

The VM is powered off. To restart the VM, run `vagrant up`
manzanita:vmware-test jacob$ vagrant up --debug &> vagrant.2-vagrant-up.log (I renamed this to vagrant.3-vagrant-up.log later)

The only actions on my part interleaved between the up, halt and up commands were to check the contents of the two VMWare files in another terminal window.

After the first vagrant up:

manzanita:~ jacob$ grep add_nat_portfwd /Library/Preferences/VMware\ Fusion/networking
add_nat_portfwd 8 tcp 2222 192.168.223.179 22
add_nat_portfwd 8 tcp 8080 192.168.223.179 80

manzanita:~ jacob$ grep -A 15 incomingtcp /Library/Preferences/VMware\ Fusion/vmnet8/nat.conf
[incomingtcp]

# Use these with care - anyone can enter into your VM through these...
# The format and example are as follows:
#<external port number> = <VM's IP address>:<VM's port number>
#8080 = 172.16.3.128:80
# VAGRANT-BEGIN: /Users/jacob/Documents/repos/vmware-test/.vagrant/machines/default/vmware_fusion/fe9e0e14-f11b-413d-a761-2ff1609cfc8d/precise64.vmx
8080 = 192.168.223.179:80
2222 = 192.168.223.179:22
# VAGRANT-END: /Users/jacob/Documents/repos/vmware-test/.vagrant/machines/default/vmware_fusion/fe9e0e14-f11b-413d-a761-2ff1609cfc8d/precise64.vmx

[incomingudp]

# UDP port forwarding example
#6000 = 172.16.3.0:6001

After vagrant halt:

manzanita:~ jacob$ grep add_nat_portfwd /Library/Preferences/VMware\ Fusion/networking
add_nat_portfwd 8 tcp 2222 192.168.223.179 22
add_nat_portfwd 8 tcp 8080 192.168.223.179 80
manzanita:~ jacob$ grep -A 15 incomingtcp /Library/Preferences/VMware\ Fusion/vmnet8/nat.conf
[incomingtcp]

# Use these with care - anyone can enter into your VM through these...
# The format and example are as follows:
#<external port number> = <VM's IP address>:<VM's port number>
#8080 = 172.16.3.128:80
2222 = 192.168.223.179:22
8080 = 192.168.223.179:80

[incomingudp]

# UDP port forwarding example
#6000 = 172.16.3.0:6001

[chrisroberts]

@jakewan Can you give me the value of VERSION in the /Library/Preferences/VMware Fusion/networking file?

[jakewan]

VERSION=1,0

Here is the whole file as it exists after the last vagrant up error:

https://gist.github.com/jakewan/ff12c192b6dcb7fd1714ca9509b7f4e5#file-networking

[femiagbabiaka]

Our development team is having the same issue, and for the time being we've had to switch over local development to Virtualbox (which works flawlessly). However, as we've already paid for a ton of licenses we'd love it if the VMWare Fusion integration worked. Is there anything we can do in terms of providing more examples or documentation to assist in solving this issue?

[jhogendorn]

We've been experiencing this bug for months now, and while its manageable with manual manipulation of files, its definitely a problem that needs to be fixed, considering the cost of the licenses etc.

As stated by @femiagbabiaka, what can we do to expedite a fix?

[vdanen]

I'm note sure why issue #7948 was closed, it's the same bloody problem and I'm still experiencing it. I've been fighting all afternoon with this and even upgraded to Fusion 8.5.8 and Vagrant 1.9.6 (was using 8.5.7 and 1.9.5 before) and it's still doing it.

This is so utterly beyond frustrating =(

[vdanen]

Also someone else opened another bug for this in issue #8642 as well, same problem.

[chrisroberts]

Hi there,

A new VMware plugin has been released. You can read more about it here:

https://www.hashicorp.com/blog/introducing-the-vagrant-vmware-desktop-plugin

It has an updated networking implementation that should resolve this underlying problem. If you still encounter this issue after upgrading, please open a new issue and I will investigate further.

Cheers!

[hashibot[bot]]

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.