Port forwarding issue on port 2222

[nycnewman]

Please note that the Vagrant issue tracker is in priority reserved for bug reports and enhancements. For general usage questions, please use
HashiCorp Discuss: https://discuss.hashicorp.com/c/vagrant/24 Thank you!

When submitting a bug report, please provide the minimal configuration and required information necessary to reliably reproduce the issue. It
should include a basic Vagrantfile that only contains settings to reproduce the described behavior.

Tip: Before submitting your issue, don't hesitate to remove the above introductory text, possible empty sections (e.g. References), and this tip.

Vagrant version

Run vagrant -v to show the version. If you are not running the latest version
of Vagrant, please upgrade before submitting an issue.

vagrant 2.2.9
vagrant-vmware-plugin 2.1.1
VMWare Fusion 11.15.5

Host operating system

This is the operating system that you run locally.

MacOS 10.15.6

Guest operating system

This is the operating system you run in the virtual machine.

MacOS 10.15.6

Vagrantfile

# Copy-paste your Vagrantfile here (but don't include sensitive information such as passwords, authentication tokens, or email addresses)
provider = ENV["PROVIDER"] || "vmware_desktop"

providers = { "vmware_desktop" => [57344, 10],
              "virtualbox" => [4096, 1] }

raise "invalid provider: #{provider}" unless providers.member? provider
token = ENV["VSTS_TOKEN"] || "unset"
name = ENV["GUEST_NAME"] || "unset"

Vagrant.configure("2") do |config|
  config.vm.box = "azure-ci-node"
  config.vm.boot_timeout = 900 # 15 minutes
  config.vm.synced_folder ".", "/vagrant", disabled: true
  config.vm.provider provider do |prov|
    prov.gui = false
    prov.memory = providers[provider][0]
    prov.cpus = providers[provider][1]
  end
  config.vm.provision "shell" do |script|
    script.path = "init.sh"
    script.args = [token, name]
  end
end

Please ensure the Vagrantfile provided is a minimal Vagrantfile which contains
only the required configuration to reproduce the behavior. Please note that if
your Vagrantfile contains an excess of configuration unrelated the the reported
issue, or is in a different format, we may be unable to assist with your issue.
Always start with a minimal Vagrantfile and include only the relevant configuration
to reproduce the reported behavior.

Debug output

Provide a link to a GitHub Gist containing the complete debug output:
https://www.vagrantup.com/docs/other/debugging.html. The debug output should
be very long. Do NOT paste the debug output in the issue, just paste the
link to the Gist.

Expected behavior

What should have happened?

Node should come up and provision.

Actual behavior

What actually happened?

Guest node comes up and is in status running but provision step fails

Steps to reproduce

1. shutdown and detroy an existing guest
2. start new instance

References

Are there any other GitHub issues (open or closed) that should be linked here?
For example:

• NAT DNS Proxy Option? #1234
• ...

[soapy1]

Hey there, thanks for opening up an issue. In order to better understand what is going on here, could you provider a gist of the debug output. https://www.vagrantup.com/docs/other/debugging.html

[nycnewman]

https://gist.github.com/nycnewman/2f66a9bd7e5eb6ec45b7dee1571c03b6

[nycnewman]

I have a nightly rebuild process that destroys and then recreates a guest instance. Seeing two issues

• Panic from underlying operating system (only started recently after 10.15.6 and 11.15.5 upgrades)
• Failure to properly provision a node due to port 2222 conflict.

On the latter the node appears to come up correctly but then fails to complete nat forwarding. Node can be manually provisioned as it is active and can connect

[soapy1]

Hey there, sorry for taking so long to circle back to you on this! A new version of the vagrant-vmware-utility has been released (https://www.vagrantup.com/vmware/downloads.html). Among some of the improvements are making port forward conflict detection more stable 🚀. Does updating the utility resolve this issue for you?

[nycnewman]

i will test and revert. Thinks have been more stable since Apple released their latest patch. Not clear if these were related but environment much more resilient Edward Newman CSO / +1 917 488 4142 Digital Asset <https://digitalasset.com/>, creators of DAML <https://daml.com/>

…

On Aug 25, 2020, at 15:07, Sophia Castellarin ***@***.***> wrote: Hey there, sorry for taking so long to circle back to you on this! A new version of the vagrant-vmware-utility has been released (https://www.vagrantup.com/vmware/downloads.html <https://www.vagrantup.com/vmware/downloads.html>). Among some of the improvements are making port forward conflict detection more stable 🚀. Does updating the utility resolve this issue for you? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#11784 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD6MV3ZVTYNXZLR3RIOQPMDSCQDWLANCNFSM4PHNUCOQ>.

-- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at  http://www.digitalasset.com/emaildisclaimer.html <http://www.digitalasset.com/emaildisclaimer.html>. If you are not the intended recipient, please delete this message.

[nycnewman]

Sophia This update did not fix issue. Still seeing port conflicts on startup. Provisioning the node afterwards appears to work. Edward Newman CSO / +1 917 488 4142 Digital Asset <https://digitalasset.com/>, creators of DAML <https://daml.com/>

…

On Aug 25, 2020, at 15:08, Edward Newman ***@***.***> wrote: i will test and revert. Thinks have been more stable since Apple released their latest patch. Not clear if these were related but environment much more resilient Edward Newman CSO / +1 917 488 4142 Digital Asset <https://digitalasset.com/>, creators of DAML <https://daml.com/> > On Aug 25, 2020, at 15:07, Sophia Castellarin ***@***.*** ***@***.***>> wrote: > > > Hey there, sorry for taking so long to circle back to you on this! A new version of the vagrant-vmware-utility has been released (https://www.vagrantup.com/vmware/downloads.html <https://www.vagrantup.com/vmware/downloads.html>). Among some of the improvements are making port forward conflict detection more stable 🚀. Does updating the utility resolve this issue for you? > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub <#11784 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD6MV3ZVTYNXZLR3RIOQPMDSCQDWLANCNFSM4PHNUCOQ>. >

-- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at  http://www.digitalasset.com/emaildisclaimer.html <http://www.digitalasset.com/emaildisclaimer.html>. If you are not the intended recipient, please delete this message.

[soapy1]

@nycnewman thanks for checking that out!
The expected outcome is Vagrant should not fail when coming up regardless of a port conflict. If a port conflict occurs (for enabled ports and communicator ports), Vagrant should auto correct them proceed with bringing up the machine.
Since it seems like Vagrant is still failing when hitting a port conflict this is still an issue.