I have a 64bit host, but can't install 64bit guests

[mpack]

Note about VirtualBox 6.1.x and later. This topic has the name it has because that was how most users encountered the problem of VT-x/AMD-v hardware accelerated virtualization not being available. If the topic had been called "VT-x not available error" then newbies may not have understood the relevance. However VirtualBox since 6.1.x now requires VT-x/AMD-v to be available (or Windows NEM, but we'll leave that for now) for all VMs, whether 32bit, 64bit, single or multiple vCPU and so on. The original text remains below, the "bittedness" stuff is now less relevant, but the underlying problem and solutions have not changed.

VirtualBox requires hardware support for virtualization (Intel VT-x or AMD-v) in order to run certain categories of VM. This includes all 64bit VMs, and all VMs which use >1 CPU core. MacOS hosts require VT-x/AMD-v for every VM. Starting with VirtualBox 6.1.0 the latter is now true for all other hosts. The developers clearly feel that supporting older machines that don't have this hardware feature is no longer justified commercially.

To ensure that you can still run VMs in those categories, run through the following checklist :-

1. Note your exact CPU model or part number, then go online and check its capabilities. The CPU must be 64bit and support either Intel or AMD virtualization technologies: VT-x or AMD-v.
   .
2. You usually need to enable VT-x/AMD-v in the host PC BIOS. You need to check with your PC manual or support forum to find out how to boot into the BIOS screen. This is probably not something we here at the VirtualBox forums can help you with. Once you get there you need to look for something buried in a menu, perhaps in the security category. The option may be called something like "Enable Virtualization Technology", "Enable SVM Mode" (AMD CPUs), "Enable Vanderpool Technology" (Intel), or perhaps "Secure Virtual Mode". If you see "Virtual Directed I/O" (VT-d/AMD-Vi) then that is a different thing. If you can find the latter option but can't find the former, and it's a recent PC (post 2016) then it's likely that VT-x/AMD-v is enabled by default in your BIOS, so go to step 3! Remember to cycle power on your host PC after making and saving the BIOS changes - in this case a full restart from power off is required, just rebooting or resuming from a hibernated state may not do the job.
   .
3. If (1) and (2) are already taken care of, then make sure that no other host apps are already using VT-x/AMD-v. The usual culprits are system level debuggers, other VM platforms, and some resident anti-virus applications. This has become a particular issue with 64bit Windows desktop and server hosts - especially Win2k12, Win10 and later, as these may enable Microsoft's Hyper-v VM platform by default: this grabs ownership of VT-x and won't play nice with VirtualBox. Note: see the fourth post below for other Win10 functions that have this effect.
   .
4. When creating a VM, make sure you choose the 64-bit version of the guest OS template in <VM Settings> | General | Basic | Version, e.g. choose "Ubuntu (64 bit)" and not "Ubuntu" or "Ubuntu (32bit)", otherwise a 64-bit guest OS may refuse to install. This has become more important since VirtualBox 4.3.x, because choosing the correct template also allows other modern processor features to be visible to the guest - it's not just about 64bit capability any more.

[mpack]

Additional Notes for Windows Hosts

1. Hyper-v competes for resources and needs to be disabled. If you want to be absolutely sure that Hyper-v is gone then open an administrator command console and type "bcdedit /set hypervisorlaunchtype off". Note that this changed a boot option, hence it will only take effect on next boot. So make sure to fully power down and reboot the host after changing the Hyper-v setting.
   .
2. On some Windows hosts with an EFI BIOS, DeviceGuard or CredentialGuard may be active by default, and interferes with OS level virtualization apps in the same way that Hyper-v does. These features also need to be disabled. On Pro versions of Windows you can do this using gpedit.msc (set Local Computer Policy > Computer Configuration > Administrative Templates > System > Device Guard > Turn on Virtualization Based Security to Disabled. CredentialGuard is a subset of DeviceGuard, so disabling the former should be enough. If you cannot use gpedit for some reason then the equivalent registry hack is to find the key HKLM|SYSTEM|CurrentControlSet|Control|DeviceGuard|EnableVirtualizationBasedSecurity|Enabled and set it to 0.
   .
3. On Win10 hosts, check Settings -> Device Security > Core Isolation Details and make sure settings in this panel are turned off, reboot the host from power down if you needed to make changes.
   "Core isolation [includes] security features available on your device that use virtualization-based security"
   ...which is why they can interfere with VirtualBox.

[mpack]

Additional Notes for MacOS Hosts

MacOS hosts don't have the BIOS variations that Windows PCs generally do, so if you see these problems on a Mac host then something has gone seriously awry.

One recently introduced (2020) way to get this problem is when you try to launch a VirtualBox VM on an M1(ARM)-based MacOS host. VirtualBox is an x86 hypervisor, it is completely unusable on an ARM based host. By all rights it should refuse to install at all, but users sometimes mislead the installer by running it under the MacOS Rosetta2 emulation feature (later releases of VirtualBox 6.1.x detect this scenario and refuse to install). However that emulation is only a facade, a facade which fails thoroughly when the software tries to do something very Intel specific, such as turning on the hardware virtualization features of the supposed x86 CPU.

For a discussion of the likelihood of VirtualBox ever supporting M1 Macs, see ARM Macs: Will Virtualbox be ported?

[mpack]

The following information is courtesy of user "Socratis". He has made a list of features that Microsoft have added to Windows 10 which implicitly enable Hyper-V and therefore prevent VirtualBox from using VT-x directly. In an ideal world these should all be disabled, and please understand that Microsoft seems to be adding to this list all the time.

Here's the list that I have so far:

• Application Guard
• Credential Guard (see https://www.microsoft.com/en-us/downloa ... x?id=53337)
• Device Guard (see https://www.microsoft.com/en-us/downloa ... x?id=53337)
• <any> * Guard
• Containers
• Hyper-V
• Core isolation (disable Hypervisor enforced memory integrity).
• Virtual Machine Platform
• Windows Hypervisor Platform
• Windows Sandbox
• Windows Server Containers
• Windows Subsystem for Linux 2 (WSL2) (WSL1 does not enable Hyper-V)

If that doesn't work, enter the following command:

• 
  bcdedit /set hypervisorlaunchtype off

followed by system restart. Note that "bcdedit" is short for "boot configuration data edit", i.e. it affects what software will be loaded on the next OS boot, so it is essential that you perform a full boot from a complete power down (not a suspend and restart) in order for the changes to take effect. Leave the PC powered down for 10 seconds before starting it again. If your PC does not offer a full shutdown from the start menu you could try running "shutdown /p" from an admin command prompt. On a laptop you may have to remove the battery.

If Hyper-V cannot be disabled, e.g. due to company policy, then VirtualBox v6.x has a new ability to run via the Windows Hypervisor Platform (NEM), however Windows 10 (1809) or later is required, the feature still has bugs (as of VirtualBox 6.1.12), Microsoft keeps changing it, and it currently causes a significant drop in VM performance.