Resolving the VirtualBox code E_FAIL Problem caused by Hyper-V

Shoot! The Microsoft update this morning has caused trouble with my VirtualBox installation. Again! This is the second or third time I had to search for my blog post that is describing the resolution in an appendix. Since the number of blog posts containing the word „Hyper-V“ is increasing on my blog, I now publish the information in a separate blog post. This way, I hope to find it more quickly next time a Microsoft update is messing up with my configuration.

Error message: “VT-x is not available” | code E_FAIL

Seen with:

• VirtualBox-5.1.10-112026-Win.exe
• Microsoft Windows 10 Pro, version 1703, OS build 15063.483 or older

If you get an error message during vagrant up or when starting a VirtualBox machine, telling you that VT-x is not available, a reason may be that you have enabled Hyper-V on your Windows 10 machine: VirtualBox and Hyper-V cannot share the VT-x CPU:

$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Checking if box 'thesteve0/openshift-origin' is up to date...
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
 default: Adapter 1: nat
 default: Adapter 2: hostonly
==> default: Forwarding ports...
 default: 8443 (guest) => 8443 (host) (adapter 1)
 default: 22 (guest) => 2222 (host) (adapter 1)
==> default: Running 'pre-boot' VM customizations...
==> default: Booting VM...
There was an error while executing `VBoxManage`, a CLI used by Vagrant
for controlling VirtualBox. The command and stderr is shown below.

Command: ["startvm", "8ec20c4c-d017-4dcf-8224-6cf530ee530e", "--type", "headless"]

Stderr: VBoxManage.exe: error: VT-x is not available (VERR_VMX_NO_VMX)
VBoxManage.exe: error: Details: code E_FAIL (0x80004005), component ConsoleWrap, interface IConsole

Note: after the latest Windows 10 Pro update, the error message has slightly changed. It does not tell anymore, that VT-x is not avialable (an anti-improvement). However, the code E_FAIL remains the same.

Resolution:

found here…

Step 1: prepare your Windows machine for dual boot with and without Hyper-V

As Administrator, open a CMD and issue the commands

bcdedit /copy "{current}" /d "Hyper-V" 
bcdedit /set "{current}" hypervisorlaunchtype off
bcdedit /set "{current}" description "non Hyper-V"

Step 2: Reboot the machine and choose the “non-Hyper-V” option.

Now, the vagrant up command should not show the “VT-x is not available” error message anymore.

The problem with some Microsoft updates is, that they tend to set the „hypervisorlaunchtype“ to „auto“ in the default profile.

This time it did not help: Trying a Re-installation of VirtualBox…

I was sure the procedure would help, as it had helped several times before, but this time, it was different.

The exact error message looked like follows:

Command: ["startvm", "8646a1bd-9371-4eb4-ad7c-9517419fb7ea", "--type", "headless"]

Stderr: VBoxManage.exe: error: The virtual machine 'ubuntu-trusty64-docker_2017-02_default_1496852974046_93388' has terminated unexpectedly during startup with exit code -1073741819 (0xc0000005)
VBoxManage.exe: error: Details: code E_FAIL (0x80004005), component MachineWrap, interface IMachine

Setting the hypervisorlaunchtype to off did not help this time. Instead, a download of the latest VirtualBox software (VirtualBox-5.1.28-117968-Win.exe) and re-installation of VirtualBox has improved the behavior in the sense, that VirtualBox GUI is working again:

Do not forget to reload your system at this point! If you do not reload the system, you will see error message similar to before.

After a reload of the system, vagrant should work fine:

D:\veits\Vagrant\ubuntu-trusty64-docker_2017-02>vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Checking if box 'williamyeh/ubuntu-trusty64-docker' is up to date...
==> default: Clearing any previously set forwarded ports...
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
    default: Adapter 2: hostonly
    default: Adapter 3: hostonly
==> default: Forwarding ports...
    default: 4200 (guest) => 4200 (host) (adapter 1)
    default: 8000 (guest) => 8000 (host) (adapter 1)
    default: 8001 (guest) => 8001 (host) (adapter 1)
    default: 8002 (guest) => 8002 (host) (adapter 1)
    default: 8080 (guest) => 8080 (host) (adapter 1)
    default: 8081 (guest) => 8081 (host) (adapter 1)
    default: 8082 (guest) => 8082 (host) (adapter 1)
    default: 8083 (guest) => 8083 (host) (adapter 1)
    default: 22 (guest) => 2222 (host) (adapter 1)
==> default: Running 'pre-boot' VM customizations...
==> 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: Machine booted and ready!
==> default: Checking for guest additions in VM...
    default: The guest additions on this VM do not match the installed version of
    default: VirtualBox! In most cases this is fine, but in rare cases it can
    default: prevent things such as shared folders from working properly. If you see
    default: shared folder errors, please make sure the guest additions within the
    default: virtual machine match the version of VirtualBox you have installed on
    default: your host and reload your VM.
    default:
    default: Guest Additions Version: 5.0.24
    default: VirtualBox Version: 5.1
==> default: Setting hostname...
==> default: Configuring and enabling network interfaces...
==> default: Mounting shared folders...
    default: /vagrant => D:/veits/Vagrant/ubuntu-trusty64-docker_2017-02
==> default: Machine already provisioned. Run `vagrant provision` or use the `--provision`
==> default: flag to force provisioning. Provisioners marked to run always will still run.

Puh, that has taken 2 hours of my precious time again. Oh, Microsoft!

At least, it is working again.
🙂