Vagrant 1.9.3
MacOS 10.12.5
Ubuntu
VMware Fusion 8.5.6
Some of the defined forwarded ports would collide with existing
forwarded ports on VMware network devices. This can be due to
existing Vagrant-managed VMware machines, or due to manually
configured port forwarding with VMware. Please fix the following
port collisions and try again:
2222
Solution of this issue is described here and it works:
https://github.com/mitchellh/vagrant/issues/8489
But I am opening the ticket because I get this error almost every time I start up, after fresh reboot. And this began to fail so frequently relatively recently, maybe several weeks. I can't track, was something updated then or not, but at the moment situation is very frustrating :(
I'm having the same issue on a brand-new MacBook Pro that I got from work. There are no other virtual machines running (Vagrant, Fusion or otherwise).
Following the instructions in #8489 does not resolve the issue. The error message remains and the incomingtcp entries reappear with every vagrant up.
Vagrant: 1.9.5
VMWare Plugin: 4.0.19
VMWare Fusion: 8.5.7 (5528452)
Host OS: macOS 10.12.5
Guest OS: Ubuntu 14.04 64
Please let me know what other information I can provide to help resolve this issue. Thanks.
ETA: Got the box running by removing all add_nat_portfwd entries from /Library/Preferences/VMware Fusion/networking along with the entries from nat.conf.
I believe this to be a race condition inside Vagrant or the VMWare Plugin, as repeated execution of vagrant up fixes it quite often. The solution in #8489 _does_ work reliably, however manually editing these files is annoying and is not a long term solution.
It also seems to manifest itself significantly more than previously on faster machines - both I and @sigil66 can reliably reproduce this on a daily basis on late 2016 and early 2017 MacBook Pros respectively, but not on older machines running the same versions of all involved software.
To clarify here, I am seeing this on source builds from master (with the current release of the fusion plugin configured as per @chrisroberts' post on the Vagrant mailing list) as well as the 1.9.5 release.
I had this same issue, started failing out of the blue. I finally had to add a defined port like this:
config.vm.network :forwarded_port, guest: 22, host: 9980, id: “ssh”
which I found at https://github.com/mitchellh/vagrant/issues/3232#issuecomment-48994417
I am now hitting this issue very consistently on the following configuration:
macOS Sierra 10.12.5
VMWare Fusion 8.5.8
Vagrant 1.9.6
vmware-vagrant-fusion 4.0.20
Attempting to edit /Library/Preferences/VMware\ Fusion/vmnet8/nat.conf as several other previous comments suggest is not helping my situation at all. It seems to be a recurring regression over and over and over again. I'd love to see some major efforts put into resolving this bug once and for all as it seems to date back at least 2 years. Any debugging help you need let me know and I'll be happy to provide it.
I am also having this issue still very frequently.
We are using vagrant as part of our CI Server for running automated tests in VMWare Fusion.
I wrote a short script to wipe out the port forwarding configuration in "/Library/Preferences/VMware\ Fusion/vmnet8/nat.conf", which runs each time before I do a "vagrant up", but intermittently (every 2-3 builds) the port collision happens.
vagrant: 1.9.7
vagrant-vmware-fusion: 4.0.20
vmware fusion: 8.5.8
host: 10.11.6
guest: 10.12.5
If I can provide something for debugging, let me know!
We're seeing this in the bento builder pipelines with vmware-vagrant-fusion 4.0.22.
I have exactly the same issue, after trying to provision a new box, using nearly identical configs as my others. I tried halting other boxes, to no avail. Scrubbing entries from the vmnet8/nat.conf doesn't help as they are being reentered straight away.
macOS Sierra: 10.12.5
VMWare Fusion: 8.5.8
Vagrant: 1.9.6
vmware-vagrant-fusion: 4.0.20
Experiencing the same issue with port forwarding entries in vmnet8/nat.conf, where the # VAGRANT BEGIN ... & # VAGRANT END tags get scrubbed, but the forward mapping is left in place resulting in port collisions and vagrant errors until the nat.conf file is manually cleaned & vmware network services are restarted via vmnet-cli:
Config:
This now happens less frequently with the latest versions of everything, but reliably happens every time following a reboot of the host machine (with or without running guests, but usually with suspended guests via vagrant suspend).
Also experiencing this with:
Incredibly frustrating.
I thought this was already solved, but started running into it this week. All packages are up to date as of this date.
https://gist.github.com/catalinbostan/58940f61851c6493d8f71f3bbc55fbbc
inspired by stevenwaskey https://gist.github.com/stevenwaskey/5573a7a3b24ec6606e4ad1aa8cb10187
solved problem for Mac OS
This is still happening with the latest Vagrant and VMWare plugin on Fusion 8, along with a new pathology that occasionally assigns NICs to the wrong vmnets (I'll open a separate issue for that when I get a chance).
Hi there,
A new VMware plugin has been released: https://www.hashicorp.com/blog/introducing-the-vagrant-vmware-desktop-plugin
It has an updated networking implementation that should resolve this issue. If you still experience issues after upgrading, please open a new issue and I will investigate further.
Cheers!
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.
Most helpful comment
I believe this to be a race condition inside Vagrant or the VMWare Plugin, as repeated execution of
vagrant upfixes it quite often. The solution in #8489 _does_ work reliably, however manually editing these files is annoying and is not a long term solution.It also seems to manifest itself significantly more than previously on faster machines - both I and @sigil66 can reliably reproduce this on a daily basis on late 2016 and early 2017 MacBook Pros respectively, but not on older machines running the same versions of all involved software.