@
scottgus1:
scottgus1 wrote:To be honest, I haven't noticed the true or false part. I could be and probably am wrong...
After consulting the VirtualBox source code and some older posts from user
socratis, you seem to be wrong in assuming to be wrong, because you're probably right.
VBox.log file wrote:00:00:59.872097 HM: HMR3Init: Attempting fall back to NEM: VT-x is not available
[...]
00:00:59.903329 VT-x is not available (VERR_VMX_NO_VMX)
1) The VMX bit in the CPUID is not set. This happens either when VT-x is not enabled in the (UEFI) BIOS, or when VirtualBox is running under another hypervisor (e.g. Hyper-V) that intercepts the CPUID command and hides the VMX bit in the response. Assuming the latter case as the only possibility to proceed, VirtualBox tries to use Hyper-V (
NEM, Native Execution Mode).
VBox.log file wrote:00:00:59.901881 VMSetError: WHvCapabilityCodeHypervisorPresent is FALSE! Make sure you have enabled the 'Windows Hypervisor Platform' feature.
2) The
Windows Hyper-V Capability HypervisorPresent is not available. This means that the API necessary to programmatically create a
Hyper-V partition (VM) is not available, and since VirtualBox cannot proceed without this API, it asks for the
Windows Hypervisor Platform to be installed (*). But
before this check is made, ...
1.5) ... VirtualBox has already detected that it is running under another hypervisor (the
HVP (HyperVisor Present) bit in the CPUID is set). This is not reflected by a log file message, because it is the expected situation after the decision to try Hyper-V.
*) Either the
Windows Hypervisor Platform is not installed, or it doesn't exist at all in Windows 10 1803 used here.
@
ahm_bj:
What does that all mean? We know that VirtualBox is running under another hypervisor (1.5). The hypervisor could be the expected one (Hyper-V) or another one (e.g. VMware ESXi), and it must be disabled for VirtualBox to proceed. For the methods if the hypervisor is Hyper-V, see the second-to-previous post by
scottgus1:
viewtopic.php?f=7&t=97134#p473652