vagrant
vagrant copied to clipboard
vagrant up times out on 'default: SSH auth method: private key' when 'VirtualMachinePlatform' Windows Feature is enabled
Vagrant version
Vagrant 2.2.10
Host operating system
Windows 10 Home - Version 20H2 (19042.572)
Guest operating system
laravel/homestead
Vagrantfile
Vagrant.configure("2") do |config|
config.vm.box = "laravel/homestead"
end
I haven't specified a provider. I have the Virtualbox Version 6.1.16 r140961 (Qt5.6.2)
Debug output
https://gist.github.com/lwpamihiranga/ec3b306a5fa8e400964096d7b476191f
Expected behavior
vagrant up
should successfully spin up the box even when the WindowsFeature VirtualMachinePlatform
is enabled
Actual behavior
vagrant up
times out on default: SSH auth method: private key
when the WindowsFeature VirtualMachinePlatform
is enabled but it does not timeout(works fine) if I run vagrant up
when WindowsFeature VirtualMachinePlatform
is disabled
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'laravel/homestead'...
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'laravel/homestead' version '9.6.1' is up to date...
==> default: Setting the name of the VM: laravel-test-minimum_default_1603343961170_29543
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
default: Adapter 1: nat
==> default: Forwarding ports...
default: 22 (guest) => 2222 (host) (adapter 1)
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
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.
Steps to reproduce
- WindowsFeature
VirtualMachinePlatform
should be enabled. If not enable it by running the following command on PowerShell as Administrator:dism.exe /online /Enable-Feature /FeatureName:VirtualMachinePlatform /all /NoRestart
. Thenrestart
the machine - Run
vagrant up
References
- #11931
- #11890
- #11741
Note: I have enabled WSL 2 in my machine. The WindowsFeature VirtualMachinePlatform
is necessary for WSL 2
Hi,
I can reproduce the error and after DISABLING the VirtualMachinePlatform
vagrant gets up again... very annoying cause I am working with WSL2, too. Maybe the problem is that WSL2 uses SSH to connect to the Linux Subsystem and so SSH in vagrant does not work?
I have the same issue. I am using many ubuntu boxes. After installing WSL2 suddenly all boxes stopped working - hang during VM boot at tthe step 'default: SSH auth method: private key'. I found the suggestion on SO to disable the VirtualMachinePlatform feature and voila - everything automagically works again.
Very annoying, as I definitely want to use WSL side by side with vagrant.
In fact, when the vagrant hangs (and timeouts after that), the machine boots up fine - I can log in to it from VB, but it is not configured for vagrant - SSH auth not setup, so vagrant ssh
does nothing. I can even provision it (vagrant up --provision
) and execute custom provision scripts. Maybe WSL brings along its own binary for ssh which does not work with vagrant but gets picked up from the PATH?
Can also confirm this issue happened after enabling WSL2 (Ubuntu) and Hyper-V on Windows 10 Home. Only sort-of solution: which only sometimes works is to keep trying vagrant reload
. Doesn't always work though :(
Also looks like someone filed a issue in the Microsoft/WSL repo regarding this here https://github.com/microsoft/WSL/issues/4599
Looks like right now you can only have either-or running. I've tried shutting down WSL and/or the distro running and it does not work.
Workaround for now for me was to disable the VirtualMachinePlatform
feature in windows by running:
Disable-WindowsOptionalFeature -Online -FeatureName "VirtualMachinePlatform"
When I need to use Docker, I'll re-enable the feature:
Enable-WindowsOptionalFeature -Online -FeatureName "VirtualMachinePlatform"
Depending on your setup/Windows version, you may need to use DSIM.
Same issue here.
My current workaround is to open VirtualBox Manager and select the virtual maschine, my vagrant is boooting up. It seems wiered but having the vm just in focus in VirtualBox GUI during vagrant up
solves the problem
This is also a problem when using vagrant running on VMWare Workstation Pro 15. Which is annoying, since VMWare Workstation supports Hyper-V just fine, it's just vagrant that hangs. Curiously, rebooting my host usually fixes it, until the next time I do a vagrant reload.
I was able to fix this by changing the Paravirtualization Interface for the VirtualBox machine from "Legacy" to either "Default" or "KVM". This can also be configured in the Vagrantfile with --paravirtprovider
. I have no idea why this issue exists or why this resolves it. My guest is Linux (CentoOS).
Disabling I/O APIC also solved the issue but I believe this prevents use of multiple CPUs.
After a couple of days of trying to solve the problem with "SSH auth method: private key", it was found that windows 10 has a conflict with vagrant.
As a tool to validate the status of virtualization, the program was used: "https://www.intel.com/content/www/us/en/download/12136/28539/intel-processor-identification-utility-windows-version .html "
I show you the capture of the initial state: https://i.imgur.com/hidKDRN.png
Fix it by disabling the following windows features: https://i.imgur.com/ZzjryTA.png
Once the aforementioned features were deactivated and the computer was restarted, I share the new state of the processor where it is evident that virtualization is already working: https://i.imgur.com/IVzh4YR.png
PS: On saying that you already activate virtualization on the board (bios)
With this solution already vagrant works perfectly for me.
I managed to solve this (I have Windows Hypervisor Platform disabled) by removing VirtualBox Host-Only Ethernet Adapter #3
(Oracle VM VirtualBox manager > File > Host Network Manager) which was set as Network Adapter 2 for vagrant on my machine.
It should be recreated again next time you run vagrant up
- but this time working along with WSL2.
Before starting vagrant I've started wsl to make sure that it's vEthernet (WSL)/ Hyper-V Virtual Ethernet Adapter is running in background as it was causing trouble before.
Credit goes to this stackoverflow Answer.
By the way: Next thing I was going to try is the VirtualboxWSL2 plugin.
I installed Docker Desktop on my Ubuntu yesterday, and today I can't ssh private key to any virtualbox vagrant machine.
I had a similar issue. Can you run this in PS to disable it:
Disable-WindowsOptionalFeature -Online -FeatureName "VirtualMachinePlatform"
When I need to use Docker, I'll re-enable the feature:
Enable-WindowsOptionalFeature -Online -FeatureName "VirtualMachinePlatform"
On Tue, Apr 12, 2022 at 10:53 AM maltewhiite @.***> wrote:
I installed Docker Desktop on my Ubuntu yesterday, and today I can't ssh private key to any virtualbox vagrant machine.
— Reply to this email directly, view it on GitHub https://github.com/hashicorp/vagrant/issues/11987#issuecomment-1096834970, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC3GJMEYKRXBTBZIOF27YLLVEWE57ANCNFSM4S2WNC7A . You are receiving this because you are subscribed to this thread.Message ID: @.***>
I'm having the same issue, but it works with VirtualBox as a provider. It's when I use docker as a provider that it hangs at 'ssh auth method'. If I remove VirtualMachinePlatform, then docker won't start. I can see the docker screen for a few seconds in the VirtualBox preview. The guest activity shows CPU at almost 100%. No idea what it's doing. Eventually it times out; I've never been able to figure out how to get in.
@jtrod - Oh sorry, I didn't see your message.
What is PS?
I am on Linux, so I don't think disabling windows features would do anything.
You are right. My comment was for Windows users only, sorry.
PS stands for PowerShell
After a couple of days of trying to solve the problem with "SSH auth method: private key", it was found that windows 10 has a conflict with vagrant.
As a tool to validate the status of virtualization, the program was used: "https://www.intel.com/content/www/us/en/download/12136/28539/intel-processor-identification-utility-windows-version .html "
I show you the capture of the initial state: https://i.imgur.com/hidKDRN.png
Fix it by disabling the following windows features: https://i.imgur.com/ZzjryTA.png
Once the aforementioned features were deactivated and the computer was restarted, I share the new state of the processor where it is evident that virtualization is already working: https://i.imgur.com/IVzh4YR.png
PS: On saying that you already activate virtualization on the board (bios)
With this solution already vagrant works perfectly for me.
I had the same issue and trying your solution works fine. In my case I have two different Vagrant with Homestead/Laravel boxes and only the second had this problem. I have Docker Desktop installed on my Windows 10, too. I will test if it works fine disabing this feature.
I have this issue, the solution is to disable WSL/Hyper-V yet a workaround to getting the box to boot is to open VirtualBox and click on the box your booting up and then run vagrant up
.
Very quirkily but it's a workaround if you want to have Docker, WSL and Vagrant running at the same time on a Windows 10+ machine.
After a couple of days of trying to solve the problem with "SSH auth method: private key", it was found that windows 10 has a conflict with vagrant.
As a tool to validate the status of virtualization, the program was used: "https://www.intel.com/content/www/us/en/download/12136/28539/intel-processor-identification-utility-windows-version .html "
I show you the capture of the initial state: https://i.imgur.com/hidKDRN.png
Fix it by disabling the following windows features: https://i.imgur.com/ZzjryTA.png
Once the aforementioned features were deactivated and the computer was restarted, I share the new state of the processor where it is evident that virtualization is already working: https://i.imgur.com/IVzh4YR.png
PS: On saying that you already activate virtualization on the board (bios)
With this solution already vagrant works perfectly for me.
@NestorLV this is not an answer he specifically said
Note: I have enabled WSL 2 in my machine. The WindowsFeature VirtualMachinePlatform is necessary for WSL 2
did you really read the question?
I had a similar issue. Can you run this in PS to disable it: Disable-WindowsOptionalFeature -Online -FeatureName "VirtualMachinePlatform" When I need to use Docker, I'll re-enable the feature: Enable-WindowsOptionalFeature -Online -FeatureName "VirtualMachinePlatform" … On Tue, Apr 12, 2022 at 10:53 AM maltewhiite @.> wrote: I installed Docker Desktop on my Ubuntu yesterday, and today I can't ssh private key to any virtualbox vagrant machine. — Reply to this email directly, view it on GitHub <#11987 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC3GJMEYKRXBTBZIOF27YLLVEWE57ANCNFSM4S2WNC7A . You are receiving this because you are subscribed to this thread.Message ID: @.>
Are you restarting your PC each time you change this?
Yes. A reboot is needed
If you guys have git bash
,
(when you right-click any space inside a folder, you may see 'Open Git Bash here' if you installed Windows Git)
Try vagrant up
with git bash
. It may works.
In Fedora 38 you can solve this issue by putting your private key in private_key file under location .vagrant/machines/default/virtualbox This has solved my issue.
running into this on Vmware Workstation Pro version 17, and removing the 'Host Only' network did do the trick.