Out of nowhere I recently started to get problems with Vagrant running on a Windows 11 host. The “vagrant up” command would always hang at the “SSH auth method: private key” stage. You can see an example of the output here.
default: SSH address: 127.0.0.1:2222 default: SSH username: vagrant default: SSH auth method: private key Timed out while waiting for the machine to boot. This means that Vagrant was unable to communicate with the guest machine within the configured ("config.vm.boot_timeout" value) time period. If you look above, you should be able to see the error(s) that Vagrant had when attempting to connect to the machine. These errors are usually good hints as to what may be wrong. If you're using a custom box, make sure that networking is properly working and you're able to connect to the machine. It is a common problem that networking isn't setup properly in these boxes. Verify that authentication configurations are also setup properly, as well. If the box appears to be booting properly, you may want to increase the timeout ("config.vm.boot_timeout") value.
I didn’t get the same issue on other hosts (Windows 10 and macOS), so I figured it was something specific to Windows 11.
That started me Googling, which came back with a bunch of results, each of which appeared to work for some people, but not all. I’ve just found one that worked for me, so I figured I would write this post to bring together the fixes I tried, regardless of success for me. If you are experiencing this issue, maybe one of these will fix things for you.
Kernel Panic – Add more vCPUs
This was my issue, and of course it was the last suggestion I found. Typical! After trying all of those proposed fixes below I eventually started watching the VirtualBox console during boot and I noticed there was a kernel panic being reported, and the boot was stalling. This seemed to be different to all the other problems people were encountering. When I started to Google for VirtualBox kernel panics, I came across a forum thread where people said they were seeing this when they had a VM with a single vCPU. It just so happened my problems were occurring when I was doing a RAC build, where the DNS node has a single vCPU. Since you build the DNS node first, I was being blocked. I never thought to try other builds, as the DNS build was the simplest and quickest. 🙂
As soon as I switched the DNS node to use 2 vCPUs the kernel panics stopped and I was able to move forward.
Some references suggest maxing out the video memory also. This can be done by adding the following entry to the Vagrantfile.
vb.customize ["modifyvm", :id, "--vram", "128"]
Using a single vCPU for the DNS node worked fine on Windows 10. My Windows 10 machine has the same version of VirtualBox and Vagrant installed, so it wasn’t anything to do with those software versions directly.
Extend Boot Timeout
The notes produced by the timeout suggest increasing the timeout by adding the following to the Vagrantfile.
config.vm.boot_timeout = 600
Needless to say this was the first thing I tried and it didn’t work for me.
Some people experienced this symptom when the virtualization features were disabled in their BIOS. I checked my BIOS and all the virtualization features were enabled, so this wasn’t my issue.
Some people updated their BIOS, which fixed the issue for them.
Windows Hypervisor Clash
Some people experienced a similar symptom when they had Hyper-V enabled on their PCs. The recommendations vary, but many people suggest turning off the following features.
- Hyper-V (this was not present on my PC)
- Virtual Machine Platform (already disabled for me)
- Windows Hypervisor Platform (already disabled for me)
I found several threads discussing this, but this is the thread I remember seeing first.
If you want to check this, click the Windows button and type “Turn Windows features on or off” to open the dialog.
VirtualBox and Vagrant Software Versions
Some people experienced a similar symptom after upgrading VirtualBox, Vagrant or both. I had recently upgraded to VirtualBox 6.1.38 and Vagrant 2.3.0, but both had worked fine (I think) since the upgrade. Despite this I tried the following:
- Removing VirtualBox and Vagrant and installing the previous versions.
- Removing VirtualBox and Vagrant and installing the previous version of Virtual Box, and the latest version of Vagrant.
- Removing VirtualBox and Vagrant and installing the latest version of Virtual Box, and the previous version of Vagrant.
None of these made a difference for me, so I concluded it wasn’t related to the version of VirtualBox and Vagrant specifically.
Cable Connected for Network Adapter
For some people their virtual networks were not marked as connected, as shown by checking out the network adapters in the VirtualBox setting for the resulting VM. To fix this they added the following to their Vagrantfile.
config.vm.provider "virtualbox" do |vb| vb.customize ["modifyvm", :id, "--cableconnected1", "on"] end
My network adapters were all marked as “Cable Connected”, even without this Vagrantfile setting, so this wasn’t my problem.
Some people were having general problems using the default insecure keys. In case you didn’t know, Vagrant boxes are built using a known insecure key. Once you create a VM from a box a new secure key is created and the insecure key is removed. It’s just a way to make sure Vagrant can always connect without a password the first time it boots a new VM.
For some people this default action was causing them problems, so they registered their own secure key and booted the boxes directly with this, setting the secure key in the Vagrantfile.
It’s unfortunate that several situations can result in the same symptom, which lead me to chase my tail for several days. Fortunately I had other machines I could use for builds, so I wasn’t totally stumped.
Hopefully you won’t have to, but if you run into this issue, give some of these a try and see if any of them fix things for you.