When using VMWare Workstation 16.2, if we try to create Windows VM, we get the following error when starting the Virtual Machine.
VMware Workstation unrecoverable error: (vcpu-0)
Exception 0xc0000005 (access violation) has occurred.
A log file is available in "C:\Users\name\Documents\Virtual
Machines\Windows_Server_2019\vmware.log".
You can request support.
To collect data to submit to VMware support, choose "Collect Support
Data" from the Help menu.
You can also run the "vm-support" script in the Workstation folder
directly.
We will respond on the basis of your support entitlement.
There are no official communication from VMWare at this moment.
This issue appears to be caused by the setting that allows VMWare to work alongside Hyper-V. There are two fixes, if you want to use Hyper-V along with your VMWare solution, we need to set the core count and processor count to 1.
This should solve the issues, but this isn't ideal.
The other option is to disable Hyper-V. I came across this when I was trying to run Faceit-AntiCheat Client. It needs Hyper-V to be disabled. If we follow the following steps we can disable Hyper-V and the VM should work fine.
Click Start and search for Command Prompt
Right-click on Command Prompt and then click Run as administrator
If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue
Then type: "bcdedit /set hypervisorlaunchtype off" Press enter
Then type:reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v "Enabled" /t REG_DWORD /d 0 /f Press enter again.
Restart your computer
Now you should be able to start the VM with the desired number of processors.
I did not get the same results.
I ran the bcdedit and reg add with confirmation that it "worked", it did not. I also set the processor to 1/1 after reset.
VMWare 16.2 Windows 10 and Windows Server 2019 clients (both updated and working on another system with NVIDA graphics card
specs below
[System Summary]
Item Value
OS Name Microsoft Windows 11 Pro
Version 10.0.22000 Build 22000
Other OS Description Not Available
OS Manufacturer Microsoft Corporation
System Manufacturer Dell Inc.
System Model Precision 7560
System Type x64-based PC
System SKU 0A69
Processor 11th Gen Intel(R) Core(TM) i7-11850H # 2.50GHz, 2496 Mhz, 8 Core(s), 16 Logical Processor(s)
BIOS Version/Date Dell Inc. 1.7.0, 12/10/2021
SMBIOS Version 3.2
Embedded Controller Version 255.255
BIOS Mode UEFI
BaseBoard Manufacturer Dell Inc.
BaseBoard Product 03DXD2
BaseBoard Version A00
Platform Role Mobile
Secure Boot State Off
PCR7 Configuration Elevation Required to View
Windows Directory C:\Windows
System Directory C:\Windows\system32
Boot Device \Device\HarddiskVolume3
Locale United States
Hardware Abstraction Layer Version = "10.0.22000.1"
User Name BAE0004233\GXP
Time Zone US Mountain Standard Time
Installed Physical Memory (RAM) 32.0 GB
Total Physical Memory 31.2 GB
Available Physical Memory 23.2 GB
Total Virtual Memory 36.2 GB
Available Virtual Memory 25.9 GB
Page File Space 5.00 GB
Page File C:\pagefile.sys
Kernel DMA Protection Off
Virtualization-based security Running
Virtualization-based security Required Security Properties
Virtualization-based security Available Security Properties Base Virtualization Support, DMA Protection, UEFI Code Readonly, SMM Security Mitigations 1.0, Mode Based Execution Control, APIC Virtualization
Virtualization-based security Services Configured Hypervisor enforced Code Integrity
Virtualization-based security Services Running Hypervisor enforced Code Integrity
Windows Defender Application Control policy Enforced
Windows Defender Application Control user mode policy Off
Device Encryption Support Elevation Required to View
A hypervisor has been detected. Features required for Hyper-V will not be displayed.
i have this problem when opening a virtual machine in virtual box:
Not in a hypervisor partition (HVP=0) (VERR_NEM_NOT_AVAILABLE).
VT-x is disabled in the BIOS for all CPU modes (VERR_VMX_MSR_ALL_VMX_DISABLED).
Result Code:
E_FAIL (0x80004005)
Component:
ConsoleWrap
Interface:
IConsole {872da645-4a9b-1727-bee2-5585105b9eed}
i searched for a solution and i found that i must enable the virtualization from the the BIOS setup but when i checked it i found it enabled. can anyone provide me a solution?
Start your PC, press F2 or F12 or DEL, go to the security option and enable VT technology.
In some new BIOS, it called Virtual technology or Intel virtualization in the CPU setting option
If I use basic session, everything works fine, but when I connect in enhanced mode, login prompt is not appearing.
Guest OS: Win 10 Pro x64 Build 18990.vb_release.190921-1704
RDP services are enabled.
Event Log for RemoteDesktopServices-RDPCoreTS/Operational shows a error:
'Failed GetConnectionProperty' in CUMRDPConnection:QueryProperty at 3318 err=[80004001] (RemoteFX module)
Host OS: Win 10 Pro x64 1903 (18362.418)
Hper-V Version: 10.0.18362.1
I disabled RemoteFX in Guest OS with policies, how it is described here, but still no success.
I had the same problem until I stumbled across this Microsoft thread where someone said, "disabling Windows Hello on the VM did the trick for some reason."
Go to Settings -> Accounts -> Sign-in options. Turn off the setting for "Only allow Windows Hello sign-in for Microsoft accounts on this device (Recommended)". Then reboot the VM and enhanced sessions should work.
I have applied some windows updates on both my host (Windows 10) and my Hyper-V guest (Windows 10). After rebooting the hyper-v VM cant boot anymore displaying the message that there is no active boot item for booting from UEFI.
After some trail and error, the solution was to reinstall hyper-v on my windows 10 host.
Ensure that hardware virtualization support is turned on in the BIOS settings
Configure networking for the Hyper-V environment to support external network connections. Also ensure that a virtual switch has been created and is functional
Remove all security software and AV
System and drivers are up-to-date.
Also, try to use PowerShell command-line to enable Hyper-V.
Install-WindowsFeature –Name Hyper-V -ComputerName <computer_name> -IncludeManagementTools -Restart
I've been having some issues getting vagrant version 1.8.1 to run with virtualbox 5.0.10, box precise64. My operating system is Windows 7.
Essentially, when I run
vagrant up
...this happens
So far, I've attempted the following:
opening another command line and running a myriad of different codes, including:
vagrant ssh
vagrant ssh-config
ssh 127.0.0.1
I've also attempted the fix shown on this video (to no avail)
https://www.youtube.com/watch?v=vDQpfb0eFTc
As well as manually specifying the ssh key, and changing the ssh key.
My attempts to ssh into the box manually are met with a "connection refused" error.
When I open the VM GUI through virtualbox, it stops at the login page, rather than the boot menu others have reported.
My vagrantfile is unmodified, however I've attempted all of the above with additions:
config.ssh.username = "vagrant"
config.ssh.password = "vagrant"
.. which didn't work
I also attempted adding this (with and without the above Vagrantfile additions)
config.ssh.private_key_path = "C:/Users/Luka/.vagrant.d/insecure_private_key"
Which also gave me nothing.
I know this is an old topic, but I ran into the same issue and for me the solution was to enable the Hardware virtualization in BIOS (VT-x), which is required on Windows OS to run any kind of virtual machine.
I hope this will help someone who stumbles into this.
I spent multiple hours trying to troubleshoot this issue, and tried every solution listed above and more, and I wasn't getting anywhere.
The error I was getting when running vagrant up:
[...]
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.
[...]
I decided to pursue this event I was seeing in the VirtualBox log for my running VM:
00:00:01.752390 HM: HMR3Init: Attempting fall back to NEM: VT-x is not available
When I saw that, I decided to check using the "Intel Processor Identification Utility" (from Intel's website) to verify if VT-x was enabled or not. To my surprise, it showed that "Intel Virtualization Technology" was disabled:
I was pretty sure VT-x was enabled in my BIOS, but I checked again to make sure. Indeed, VT-x was enabled in my BIOS.
Pretty stumped by what I was seeing, I kept looking on the internet as to why VT-x was enabled in BIOS, but showing as disabled by the OS. A lot of articles kept pointing at "Hyper-V" being the culprit. So I uninstalled "Hyper-V" using the Windows Features utility [as well as my Docker Desktop" because it relies on Hyper-V to function], but the Intel CPU identification utility kept showing VT-x as disabled.
Next thing I tried was to remove all the items that are identified as "interfering" with Hyper-V in the Windows 10 "Windows Features" [listed as "Turn Windows features on or off" in the search bar]. The items in red are the ones I removed:
Containers
Hyper-V
Virtual Machine Platform
Windows Hypervisor Platform
Windows Subsystem for Linux
I restarted my PC, again, I checked the status of VT-x with the CPU identification utility, and still, it was disabled.
At this point I was pretty much going to throw the towel at the issue until I found some article where someone ran this command manually in an elevated command prompt (cmd.exe):
dism.exe /Online /Disable-Feature:Microsoft-Hyper-V
I restarted my PC, checked the status of VT-x with the CPU identification utility, to my surprise it was showing as ENABLED!!:
When I checked the VirtualBox logs from my running VM after VT-x showed as enabled, I could see the following event instead:
00:00:01.556258 HM: HMR3Init: VT-x w/ nested paging and unrestricted guest execution hw support
In my command-line window, after vagrant up, I could now see:
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
default:
default: Vagrant insecure key detected. Vagrant will automatically replace
default: this with a newly generated keypair for better security.
default:
default: Inserting generated public key within guest...
default: Removing insecure key from the guest if it's present...
default: Key inserted! Disconnecting and reconnecting using new SSH key...
default: Machine booted and ready!
My solution in a nutshell?
Make sure the OS sees VT-x as enabled using a utility such as "Intel Processor Identification Utility" [Or whatever utility depending on your CPU architecture]. I believe there is a bug in Windows 10 that causes this issue, but I haven't been able to put my finger on it (and I don't have time to do so). It seems Hyper-V is the root cause of all the issues. For the people concerned about not being able to use Docker Desktop anymore, I believe there are alternatives out there for non-Hyper-V solutions (i.e. free Docker EE??).
Good luck.
Happened to me with "ubuntu/focal64". I tried different solutions, but nothing worked.
Switch box to "ubuntu/xenial64" - everything loads successfully.
My setup:
win10 home 10.0.19041 Build 19041
vagrant 2.2.9
virtualbox 6.2
I am on:
Windows 10
Vagrant 2.2.19
Virtualbox 6.1.30
I have been using laravel homestead for a long time.
A co-worker recently recommended I try docker. After installing docker desktop & configuring my machine to use WSL, I experimented with Laravel Sail over the weekend.
Then I tried to vagrant up into my normal homestead machine this morning, but my system would hang at default: SSH auth method: private key
After trying several of the other solutions above and elsewhere, here's what finally worked for me:
Open Oracle VM VirtualBox manager
File > Host Network Manager
Select "VirtualBox Host-Only Ethernet Adapter #2"
Click "Remove"
Switch to your normal terminal of choice and run vagrant up as ususal
The system will re-build the network adapter and the vagrant machine will boot up as normal. Back to work.
Credits: https://github.com/hashicorp/vagrant/issues/11987#issuecomment-903666254
And: https://stackoverflow.com/a/56318621
I also got this issue when I am trying to use laravel/homestead vagrant box. For me, I found out that the issue is caused by WindowsFeature VirtualMachinePlatform. I have enabled it since I am using WSL 2 in my machine. Simply disabling that feature helped with the issue.
To disable the VirtualMachinePlatform feature, open PowerShell as an Administrator and run:
dism.exe /online /Disable-Feature /FeatureName:VirtualMachinePlatform /NoRestart
Then Restart your machine and try vagrant up. It worked for me.
You can enable the VirtualMachinePlatform feature again by simply running the below command on PowerShell as an Administrator:
dism.exe /online /Enable-Feature /FeatureName:VirtualMachinePlatform /all /NoRestart
Then Restart your machine again and the feature is enabled again.
I have reported an issue regarding this also. If anyone needs to keep track on that bug click here
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.
This happened to me with box ubuntu/bionic64 too. By switching to ubuntu/trusty64 it runs without a problem. (Win10 Pro v2004 build 19041.572)
As state here there is a confirmed bug that causes some of the newer Ubuntu boxes to boot slowly, which is causing the SSH timeout in this case.
You can work around this by adding the following customizations to your Vagrantfile:
config.vm.provider :virtualbox do |vb|
vb.customize ["modifyvm", :id, "--uart1", "0x3F8", "4"]
vb.customize ["modifyvm", :id, "--uartmode1", "file", File::NULL]
end
It's worth to try this too if other ways didn't help yet.
In VirtualBox go to Settings, click on Network, then on Advance, then change your Network type to : Intel PRO/1000 MT Server (82545EM) and refresh the MAC-address
Make sure your Port Forwarding is set to default like this image:
Hope this helps someone as I struggled with mine for quite some time after upgrading Virtualbox, clearly I did not investigate very well due to time constraints, then after reading quite a few posts, decided to clear my known_hosts file on my machine, the the issue is now resolved.
I have also faced the issue “Vagrant up hangs at ssh auth method: private key”, after trying out a lot off stuff. But as stated above by morkitz Enabling the Hardware Virtualization solved my issue as well.
My Stack was
1. Win 8.1 Enterprise
2. Vagrant 2.1.2
3. Virtual Box 5.2.18