At least in my Win10 installation #1.
I have two Windows 10 installations on my harddisk, which do not see each other (partitions differently encrypted).
In my Win10 installation #2, VBox 6.1 runs well, but I am not sure if Hyper-V hypervisor is or is not running (details below).
My test setups: virtual machines with two cores, around 2400 MB Ram. No harddisk, but one virtual DVD drive containing KNOPPIX_V8.6.1-2019-10-14-DE.iso
The test:
- boot from the Knoppix ISO (which is a live Linux OS)
- and then within the virtual machine, from a command prompt, I have the MD5 hash be computed for the complete Knoppix DVD
- and then I have the MD5 computation repeated in order to find an MD5 discrepancy which would mean that something is wrong
Test results in Win10 installation #1:
Code: Select all
VBox 6.1.10 22 sec, but MD5 checksums different on every test run (Alas!)
VMWare Player 15.5.6 71 sec, MD5 checksum always the same
Hyper-V Manager 47/33 sec first/second test run, MD5 checksum always the same
Installation #2 has been installed by me, with no extra protection software. I have Hyper-V stuff and Windows-Hyper-V-Platform installed just for testing how Virtualbox cooperates with it, and I have no problem at all. For some strange reason, HWiNFO64.exe also claims there is a Hypervisor running, even when the Hyper-V is not installed (but I need to check this again; sorry, I prematurely pressed Submit so this post got submitted too early). Update: HWINFO64.exe is correct; Hyper-V is enforced on installation #2 because installation #1 set some EFI variables which enforce Hyper-V usage even for installation #2.
Update 2020-07-03 - More internet researching, and testing by me shows:
If a Win 10 host is running on top of Hyper-V, this always makes VirtualBox become unreliable. Then do not use VirtualBox!!!
For detecting if the Win 10 host is running on top of Hyper-V, the preinstalled console program %windir%\system32\systeminfo.exe can be used. External program HWiNFO64.exe is not needed. At the end of its output, systeminfo either tells that Hyper-V is active, or the requirements which need to be met in order to activate Hyper-V.
When booting, there are several factors where every single one enforces Hyper-V usage:
- The well known "hypervisorlaunchtype Auto" setting in the BCD store
- Some so called "EFI variable" settings in the firmware. These seem to be: Kernel_Lsa_Cfg_Flags, VbsPolicy of the variable group GUID {77FA9ABD-0359-4D32-BD60-28F4E78F784B}
- (claimed somewhere else, not verified by me) Always when Secure Boot is turned on in the firmware setup
It seems that under certain conditions (e.g. Credential Guard installed and configured appropriately) Windows 10 sets the EFI variable Kernel_Lsa_Cfg_Flags. This causes some EFI program running during the boot process (bootmgfw.efi, bootmgr.efi, WinLoad.efi, ...?) to create and set the EFI variable VbsPolicy, which determines that Hyper-V should be used for running Win 10. Note that possibly this whole EFI variable setting and Hyper-V enforcing becomes effective only after a 2nd or 3rd boot.