Port forwarding issue on port 2222

nycnewman commented 4 years ago

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

shutdown and detroy an existing guest
start new instance

References

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

GH-1234
...

soapy1 commented 4 years ago

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 commented 4 years ago

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

nycnewman commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 notifications@github.com 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 https://github.com/hashicorp/vagrant/issues/11784#issuecomment-680215729, 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 commented 4 years ago

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 edward@digitalasset.com 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 <notifications@github.com mailto:notifications@github.com> 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 https://github.com/hashicorp/vagrant/issues/11784#issuecomment-680215729, 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 commented 4 years ago

@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.

hashicorp / vagrant