vagrant icon indicating copy to clipboard operation
vagrant copied to clipboard

Apple M4 MacOS 15.5 - Parallels - bento/ubuntu-22.04 - Host Unreachable

Open sgrewelancom opened this issue 6 months ago • 8 comments

Debug output

https://gist.github.com/sgrewelancom/edca50f6e85b0ecaa4a488da304d890f

Expected behavior

Ubuntu VM should be up, and no further error message.

Actual behavior

VM in Parallels is created, can also be ssh'ed to using the obtained IP, but vagrant up still reports "host unreachable" and eventually times out with an error message.

Reproduction information

Vagrant version

Vagrant 2.4.6

Host operating system

mac OS Sequoia 15.5

Guest operating system

Ubuntu 22.04 (bento/ubuntu-22.04) (Also tested with some other compatible boxes, same issue)

Steps to reproduce

  1. Create simple vagrantfile using bento/ubuntu-22.04 as box
  2. Run 'vagrant up' on it.

Vagrantfile

# Copy-paste your Vagrantfile here. Remove any sensitive information such as passwords, authentication tokens, or email addresses.

Vagrant.configure("2") do |config|
  config.vm.box = "bento/ubuntu-22.04"
  config.vm.provider "parallels" do |prl|
    prl.memory = 2048
    prl.cpus = 2
  end
end

sgrewelancom avatar Jun 08 '25 21:06 sgrewelancom

Hi @sgrewelancom,

Thank you for the detailed report. I tried to reproduce the issue using the Vagrantfile you provided, but I didn't encounter the same problem. Based on your debug logs, it looks like SSH never became available. However, when I compare it to my own logs, SSH eventually came up after a couple of attempts.

Could you try removing the box and running it again to see if that helps?

Also, you mentioned trying a few other supported boxes—could you share which ones? I'd like to test with those as well to see if I can replicate the issue.

Additionally, could you please share the output of vagrant ssh-config? By default, it should be using a bridged network. Based on that output, could you also check what you get when you run nc -vz <IP-ADDR> <PORT>? If everything is working correctly, you should see a message like: Connection to <IP> port <PORT> [tcp/ssh] succeeded!

Thanks!

taru-garg-hashicorp avatar Jun 10 '25 11:06 taru-garg-hashicorp

Hi @taru-garg-hashicorp !

Sure, here is the output of vagrant ssh-config:

Host default
  HostName 10.211.55.40
  User vagrant
  Port 22
  UserKnownHostsFile /dev/null
  StrictHostKeyChecking no
  PasswordAuthentication no
  IdentityFile /Users/user/.vagrant.d/insecure_private_keys/vagrant.key.ed25519
  IdentityFile /Users/user/.vagrant.d/insecure_private_keys/vagrant.key.rsa
  IdentitiesOnly yes
  LogLevel FATAL
  PubkeyAcceptedKeyTypes +ssh-rsa
  HostKeyAlgorithms +ssh-rsa

And then, the output of nc -vz 10.211.55.40 22: Connection to 10.211.55.40 port 22 [tcp/ssh] succeeded!

Confusingly, the VM that is created is up and running, and I can also connect to it both via vagrant ssh as well as via ssh -i /Users/user/.vagrant.d/insecure_private_keys/vagrant.key.ed25519 [email protected]. This even works while vagrant up is still running and reporting default: Warning: Host unreachable. Retrying...

I tried removing the bento/ubuntu-22.04 box and starting again from scratch several times and also tried the same with bento/ubuntu-24.04 and bento/ubuntu-20.04. Always the same behavior.

The Vagrantfile I shared is explicitly a very basic one. When trying with the other boxes, I only replaced the value for config.vm.box, no other change. I have the same problem with Vagrantfiles that describe a more difficult setup and that provision VMs via Ansible playbooks. For the latter, my main problem is that due to this default: Warning: Host unreachable. Retrying... and eventually running into the timeout, vagrant up never gets to the provisioning step. And even trying vagrant provision explicitly after vagrant up runs into the timeout yields the same issue and will never succeed.

sgrewelancom avatar Jun 14 '25 09:06 sgrewelancom

INFO base: prlctl path: /usr/local/bin/prlctl INFO base: prlsrvctl path: /usr/local/bin/prlsrvctl INFO subprocess: Starting process: ["/usr/local/bin/prlctl", "--version"] DEBUG subprocess: Command not in installer, not touching env vars. INFO subprocess: Command not in installer, restoring original environment... DEBUG subprocess: Selecting on IO DEBUG subprocess: Waiting for process to exit. Remaining to timeout: 32000

Hi @sgrewelancom,

Thanks for the response, ssh-config looks fine, but I just found these lines in the log, is it possible that the Parallels CLI tool is not installed or is not symlinked to the mentioned paths, can you check if the commands are actually present, there was also a similar short discussion on the vagrant-parallels plugin github?

taru-garg-hashicorp avatar Jun 14 '25 16:06 taru-garg-hashicorp

Yes, I had also looked into these parts of the logs - it is not so clear to me what "command" the messages refers to. I double-checked, I have both prlctl and prlsrvctl in /usr/local/bin. prlctl version 20.3.2 (55975) prlsrvctl version 20.3.2 (55975)

My Parallels installation is also quite fresh on my newer M4 Macbook. I had vagrant and Parallels running without any issues on an M1 Macbook a couple of months back.

Some other things that I looked into and tried (unfortunately without any changes/improvements): https://github.com/Parallels/vagrant-parallels/issues/385 https://github.com/hashicorp/vagrant/issues/13558

And I also tried uninstalling and re-installing the vagrant parallels plugin, this also did not change anything.

sgrewelancom avatar Jun 14 '25 21:06 sgrewelancom

Could you try re-installing Parallels ? I don't know if that will resolve the issue, but since I am not able to replicate the issue locally, I think that's something that you can give a try ?

taru-garg-hashicorp avatar Jun 16 '25 05:06 taru-garg-hashicorp

I re-installed Parallels like you suggested, but this didn't change the behavior I described.

However, meanwhile I noticed/figured out another detail to add to the error description that might get us forward here: When I run vagrant up in a Terminal session, the IP that gets assigned to the VM initially is never pingable in this exact Terminal session, no matter how long I wait - reliably and reproducibly yielding the "Host unreachable" errors that I initially reported here. However, in another Terminal session (it does not even need to be a fresh one), the IP may be pingable, nc <IP> 22 successful, and I can ssh to the assigned IP. Not always, though - it is very strange, I could not yet figure out a pattern here. If I abort vagrant up in the original session, then right afterwards the IP of the VM sometimes is pingable, sometimes not. Whenever I have a session in which the IP is not pingable, it will also not become pingable there, even after a successful connection from another session.

And of course, in any Terminal session I have in which the IP is pingable, I can successfully and without any further errors execute all vagrant commands after aborting the initial vagrant up, e.g. vagrant provision. I tried this with both zsh and bash (the latter is a completely standard bash with no customizations whatsoever, since I usually do not use it). Both yield the exact same issues on my M4 Macbook.

sgrewelancom avatar Jun 23 '25 20:06 sgrewelancom

Adding here: I also run into exactly the "Host Unreachable" issue when trying to run the vagrant parallels provider via molecule for testing Ansible roles. Probably this is not surprising, I assume it calls exactly the standard vagrant commands internally and configures the boxes much like I do.

sgrewelancom avatar Jul 01 '25 22:07 sgrewelancom