Closed nathanejohnson closed 5 years ago
/Library/Preferences/VMware Fusion/networking:
VERSION=1,0
answer VNET_1_DHCP yes
answer VNET_1_DHCP_CFG_HASH 82E394F1FEDCF236C7162B421AA462C9704CA7FF
answer VNET_1_HOSTONLY_NETMASK 255.255.255.0
answer VNET_1_HOSTONLY_SUBNET 172.16.29.0
answer VNET_1_NAT no
answer VNET_1_VIRTUAL_ADAPTER yes
answer VNET_8_DHCP yes
answer VNET_8_DHCP_CFG_HASH FD5104577109CAA5ECB22041EDE0AE8EBABFC986
answer VNET_8_HOSTONLY_NETMASK 255.255.255.0
answer VNET_8_HOSTONLY_SUBNET 192.168.54.0
answer VNET_8_NAT yes
answer VNET_8_VIRTUAL_ADAPTER yes
/Library/Preferences/VMware Fusion/vmnet8/nat.conf:
# VMware NAT configuration file
# Manual editing of this file is not recommended. Using UI is preferred.
[host]
# NAT gateway address
ip = 192.168.54.2
netmask = 255.255.255.0
# VMnet device if not specified on command line
device = vmnet8
# Allow PORT/EPRT FTP commands (they need incoming TCP stream ...)
activeFTP = 1
# Allows the source to have any OUI. Turn this on if you change the OUI
# in the MAC address of your virtual machines.
allowAnyOUI = 1
# Controls if (TCP) connections should be reset when the adapter they are
# bound to goes down
resetConnectionOnLinkDown = 1
# Controls if (TCP) connection should be reset when guest packet's destination
# is NAT's IP address
resetConnectionOnDestLocalHost = 1
# Controls if enable nat ipv6
natIp6Enable = 0
# Controls if enable nat ipv6
natIp6Prefix = fd15:4ba5:5a2b:1008::/64
[tcp]
# Value of timeout in TCP TIME_WAIT state, in seconds
timeWaitTimeout = 30
[udp]
# Timeout in seconds. Dynamically-created UDP mappings will purged if
# idle for this duration of time 0 = no timeout, default = 60; real
# value might be up to 100% longer
timeout = 60
[netbios]
# Timeout for NBNS queries.
nbnsTimeout = 2
# Number of retries for each NBNS query.
nbnsRetries = 3
# Timeout for NBDS queries.
nbdsTimeout = 3
[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
[incomingudp]
# UDP port forwarding example
#6000 = 172.16.3.0:6001
Is the 2222
port currently in use by some other process?
@chrisroberts no, as verified by netstat -an . The funny thing is I can vagrant ssh after getting the error message.
==> default: Deleting the VM...
(njohnson@nathanmbp:~/src/simple)$ netstat -an | grep 2222
(njohnson@nathanmbp:~/src/simple)$
I'm seeing exactly the same behaviour using the Vagrantfile above.
Vagrant 2.2.3 vagrant-vmware-desktop (2.0.2, global) VMWare Fusion 10.1.5
MacOS Mojave 10.14.2
https://gist.github.com/rjshep/41f0dc6d7b3b6fe1d70ee8a9f3307e0b
Verified with netstat -an
that 2222 isn't currently in use.
I've seen this consistently for a while now. If memory serves me, it began after installing macOS Mojave and VMware Fusion 11. Currently persisting with these versions:
I'm not using the centos/7
box. It's happening me for custom Debian Jessie boxes that I build, as well as with the bento/debian-8
box.
$ netstat -an | grep '2222'
$
vagrant up --debug
output.Vagrant is 100% broken on mac fusion. This is a commercial product and it's pretty clear they're not supporting it at all. Very disappointed.
I have the same problem since today. vagrant 2.2.2, vmware fusion: 11.0.2, host: macos 10.13.6, vm: win10
Error: Port forward conflict on host port 5985
We have 2 Mac Build Nodes with the same configuration using the same VMs for our automated tests. One Node is running fine and the other one was as well since today. Came out of nowhere. Restart of the node does not help.
Hi there,
Both the vagrant-vmware-utility (v1.0.7) and the vagrant-vmware-plugin (v2.0.3) have had new versions released addressing this problem, as well as providing more debug related information to help identify where the issue is originating on problem systems. The next release will include a helper command to forcibly reset the networking state for cases where it may get out of sync.
After upgrading to the latest versions, clear out any dangling port forwards that may still exist. If issues are still encountered, please do let me know.
@chrisroberts first off thank you for responding. In my case, there were no port forwards in the networking file. Is it possible Fusion 11 defines them somewhere else?
(njohnson@greyeagle:/Library/Preferences/VMware Fusion)$ grep -v "^#" vmnet8/nat.conf | grep -v "^$"
[host]
ip = 192.168.54.2
netmask = 255.255.255.0
device = vmnet8
activeFTP = 1
allowAnyOUI = 1
resetConnectionOnLinkDown = 1
resetConnectionOnDestLocalHost = 1
natIp6Enable = 0
natIp6Prefix = fd15:4ba5:5a2b:1008::/64
[tcp]
timeWaitTimeout = 30
[udp]
timeout = 60
[netbios]
nbnsTimeout = 2
nbnsRetries = 3
nbdsTimeout = 3
[incomingtcp]
[incomingudp]
(njohnson@greyeagle:/Library/Preferences/VMware Fusion)$ cat networking
VERSION=1,0
answer VNET_1_DHCP yes
answer VNET_1_DHCP_CFG_HASH EB7EF74CF49EA43B6F972D7B8C671D577E82FED3
answer VNET_1_HOSTONLY_NETMASK 255.255.255.0
answer VNET_1_HOSTONLY_SUBNET 172.16.29.0
answer VNET_1_NAT no
answer VNET_1_VIRTUAL_ADAPTER yes
answer VNET_8_DHCP yes
answer VNET_8_DHCP_CFG_HASH 52BA0D8AB1A25A6446702BAF6D72A8810DE7448A
answer VNET_8_HOSTONLY_NETMASK 255.255.255.0
answer VNET_8_HOSTONLY_SUBNET 192.168.54.0
answer VNET_8_NAT yes
answer VNET_8_VIRTUAL_ADAPTER yes
(njohnson@greyeagle:/Library/Preferences/VMware Fusion)$ pwd
/Library/Preferences/VMware Fusion
(njohnson@greyeagle:/Library/Preferences/VMware Fusion)$ /opt/vagrant-vmware-desktop/bin/vagrant-vmware-utility --version
1.0.7
(njohnson@greyeagle:/Library/Preferences/VMware Fusion)$ vagrant plugin list
vagrant-vmware-desktop (2.0.3, global)
(njohnson@greyeagle:/Library/Preferences/VMware Fusion)$
EDIT - just to be clear, I upgraded the versions of vagrant-vmware-desktop and vagramt-vmware-utility , I have restarted the system but I'm still seeing the same failure as originally reported. Is there some debugging information you'd like?
Are there any entries listed in the settings file? This is located at /opt/vagrant-vmware-desktop/settings/nat.json
. If so, remove them (or just delete the file and let it be recreated). If you are still encountering collisions, can you provide a debug gist of a vagrant up --debug
. The extra logging that's been added will hopefully help determine what's causing this state.
Thanks!
@chrisroberts that seemed to do the trick. Thank you very much!
One more question:
Is there a way to get the vagrant-vmware-utility to restart, or to convince it to synchronize the nat.json file? I noticed at one point it still complained of a conflict even after wiping the file, and then when I did a vagrant destroy the old value was flushed to disk.
You can restart it with launchctl or even just kill
it and it'll get restarted.
I struggled on two MBP in the last few days. All updated to latest versions Vagrant 2.2.5, vagrant-vmware-utility 1.0.7, vagrant-vmware-desktop plugin 2.0.3, VMware Fusion Pro 11.1.0 but the port conflict stopped me from using Vagrant. OK, the VM starts, but I cannot provision or use the shared folder.
Now I've deleted all port forwardings in
sudo vi "/Library/Preferences/VMware Fusion/vmnet2/nat.conf"
sudo vi "/Library/Preferences/VMware Fusion/networking"
rm -rf .vagrant
rebooted and ran a fresh vagrant up
, but the error still exists.
$ vagrant up 2019-box
Bringing machine '2019-box' up with 'vmware_fusion' provider...
==> 2019-box: Cloning VMware VM: 'StefanScherer/windows_2019_docker'. This can take some time...
==> 2019-box: Checking if box 'StefanScherer/windows_2019_docker' version '2019.07.11' is up to date...
==> 2019-box: Verifying vmnet devices are healthy...
==> 2019-box: Preparing network adapters...
==> 2019-box: Starting the VMware VM...
==> 2019-box: Waiting for the VM to receive an address...
==> 2019-box: Forwarding ports...
2019-box: -- 5985 => 55985
2019-box: -- 5986 => 55986
2019-box: -- 22 => 2222
Vagrant failed to apply the requested port forward. The following
error message was generated while attempting to apply the port
forward rule:
Port forward conflict on host port 55986
Please resolve any problems reported in the error message above and
try again.
After I found this blog post https://www.cryptica.me/blog/port-forward-collision/ I additionally did
sudo rm -f /opt/vagrant-vmware-desktop/settings/nat.json
sudo killall vagrant-vmware-utility
vagrant up
And it works again 😅
Alternatively, you can do this
config.vm.network "forwarded_port", guest: 22, host: 2497, id: 'ssh'
This issue should be reopened... Issue persists with Vagrant 2.2.5 and VMWare Fusion 11.1.1
vagrant up --debug
output:
log.txt
Issue still persists for me.
2.2.5 and VMWare plugin 2.0.3 on VMWare Fusion 11
Is there a way to fix this problem?
My Lab:
@meyerf99 probably manually clean these two files from old port forwardings might help. As I have to cleanup the nat network from time to time and always forget the commands, I've put it into a small script. But you have to edit the files manually, I haven't automated that ;-)
#!/bin/bash
sudo vi /opt/vagrant-vmware-desktop/settings/nat.json
sudo vi "/Library/Preferences/VMware Fusion/vmnet8/nat.conf"
sudo killall vagrant-vmware-utility
@StefanScherer Thanks for your solution, it helped :)
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
Vagrant 2.2.2 vagrant-vmware-desktop (2.0.2, global) VMWare Fusion 11.0.2
Host operating system
MacOS Mojave 10.14.2
Guest operating system
Centos 7
Vagrantfile
Debug output
https://gist.github.com/e8989091240f2f703b18b8664d6b9281
Expected behavior
it should pull up the VM
Actual behavior
Error message
Steps to reproduce
vagrant up
References