virtualbox.org

I'm posting this in the hope that it will save someone time and effort.

Host: Windows 10 Home Version 2004
AMD Ryzen 3 2300X Quad Core CPU on Asus A320M-K MB
Virtualisation on this MB is off by default and enabled by a setting in the BIOS.
Guest OSs: Ubuntu 20.04 and CentOS 8

I created a couple of Linux guest VMs on this windows host and they worked acceptably well for a few weeks.
Then the SSD failed and I had to restore the *vdi files from backup.
The restored VMs had been running on another machine with a Ryzen 7 CPU without issue.
Soon after starting the VMs on a new SSD, a variety of problems started. Initially it was random problems with crashing, Gnome restarting, updates not working properly (failing with authentication errors). I realised this was affecting both VMs.
I made sure that Hyper-V was off (it was).
Windows Device Security > Core Isolation was off.
The same VMs (same original *.vdi files) were running smoothly on the Ryzen 7 machine so I knew something must be wrong with my Ryzen 3 setup.
Comparing the settings on the two machines, the only difference was the "VM Execution Engine" as reported by the virtualbox session information tool.
On the Ryzen 7 it was reported as "VT-x/AMD-V", on the Ryzen 3 it was "NativeAPI".
In spite of checking the "Enable Nested VT-x/AMD-V" setting on vbox, the Ryzen 3 VM refused to change from "NativeAPI".
What I did to fix:
Toggled virtualisation support OFF in the BIOS and attempted to start the VM (failed)
Toggle virtualisation support ON in the BIOS and checked the "Enable Nested VT-x/AMD-V" setting on vbox
On next VM start, the session information on the Ryzen 3 reported "VT-x/AMD-V" and the crashes/random errors went away.
I've searched "NativeAPI" on the forums here but can't see anything related to my problem.
In summary, if you see "NativeAPI" as the VM Execution Engine, and your VM is flaky, something's not right!

Interesting thoughts, Grindlay!

I am wondering, based on how you fixed the problem, if the underlying cause mught have been Hyper-V being enabled on the new host PC.

Can you please identify for me what is the "virtualbox session information tool"? I looked in the vbox.logs and "vboxmanage showvminfo" and could not find any reference to "VM Execution Engine".

Start your VM then from the Host menu click Machine > Session Information (HOST + N) and the "Runtime Information" tab.
Hyper-V definitely off and never enabled on the Ryzen 3.

Fascinating! I learned something new today, I never knew that was there. Thanks!

Hyper-V is used in a lot of Microsoft services besides the "Hyper-V" that runs virtual machines. Even Windows 10 Home has Hyper-V, just not the virtual machine runner.

If you have a guest vbox.log from when you were having the problem on the new host, and before you started trying to fix it, that log could tell what the issue arose from.

FWIW I still suspect Hyper-V and that the AMD Ryzen isn't involved. The log would tell. If you have a new-host-pre-fix vbox.log, please zip it and post it using the forum's Upload Attachment tab.

Glad to have contributed something
TBH, the Vbox logs didn't show anything awry. The problems were all in the VM Linux messages and dmesg logs but I think the underlying problem was that vbox couldn't start the correct virtualisation engine, for whatever reason, on the Host.
However, I have some of the logs from when the "nativeAPI" was active so I'll dig them out and attach for your perusal.

Thanks! This particular log definitely did not have Hyper-V running:

00:00:02.233116 HM: HMR3Init: AMD-V w/ nested paging

If you can get a "NativeAPI" log it would be interesting to compare.

Spoke too soon. Changed the CPU today to a Ryzen 7 and back to "nativeAPI" and crashing
Seems like vbox VMs have difficulty tracking underlying hardware changes.

Between the previous and the current Runtime Information screenshot are a lot of differences. Additionally, the VBox.log file does not match all information. Some details:

The VBox.log file shows Hyper-V being active, this matches VM Execution Engine being native API, and Nested Paging and Unrestricted Execution being Inactive.

The Guest Additions version matches between the VBox.log file and the current Runtime Information, but not the previous Runtime Information.

What's peculiar is the Guest OS Type, being Linux 2.6 / 3.x / 4.x (64-bit) in the current Runtime Information, but Ubuntu_64 in the VBox.log file. Are you sure that this is from the same VM?

fth0 wrote:The VBox.log file shows Hyper-V being active,

Yep, it sure is:

00:00:01.759345 HM: HMR3Init: Attempting fall back to NEM: AMD-V is not available
00:00:01.772290 NEM: WHvCapabilityCodeHypervisorPresent is TRUE, so this might work...

These log lines indicate that a service using Hyper-V is enabled on your host PC.

Your problem is not the AMD CPU. (Within reason: really old CPUs might not have 'virtualization technology', in AMD's case AMD-V or SVM, then the guest would also not run.) Your 10 Home OS, though not having the ability to run Hyper-V virtual machines, has a Hyper-V-supported service or three running.

You might notice in the guest window's Status Bar the green turtle: . Your PC is of the type and OS where Virtualbox can attempt to run the guest using the Hyper-V engine. This arrangement is still being developed and isn't 100% yet.

If VirtualBox is running without Hyper-V enabled, and nothing else is interfering with hardware virtualization (VT-x / AMD-V), then the usual virtualization icon () will be seen in the Status Bar.

To turn Hyper-V off completely, do this:

1. Shut down all programs. You will have to reboot your host.

2. See I have a 64bit host, but can't install 64bit guests. This tutorial has a couple more things to look for in step 2. Be sure these are all turned off.

3. Find the Command Prompt icon, right click it and choose Run As Administrator.

4. Enter this command:

bcdedit /set hypervisorlaunchtype off

5. Enter this command:

shutdown -s -t 2

6. When the computer turns off, unplug it for 20 seconds. Then plug it in again and boot up Windows 10.

If your Virtualbox does not start successfully, zip and post another vbox.log. For further info, see https://www.tenforums.com/tutorials/139 ... puter.html

fth0 wrote:Between the previous and the current Runtime Information screenshot are a lot of differences.
What's peculiar is the Guest OS Type, being Linux 2.6 / 3.x / 4.x (64-bit) in the current Runtime Information, but Ubuntu_64 in the VBox.log file. Are you sure that this is from the same VM?

My apologies - I have a three Ubuntu guest VMs and you're right, I've mixed them up in posting their logs. I'll stick to just the one for reporting the odd behaviour.

Firstly, thanks for the great support - I really appreciate the help in trying to find a solution.
Regarding Hyper-V, I attach a screen shot of my Windows settings. I haven't attempted to change these, as I'm hoping to isolate the problem to the BIOS rather than Windows.
I agree that when "Native API" is the active Virtualization Engine, the logs confirm that "AMD-V is not available". The question is why.
I've also attached a sequence of screen shots that help to clarify how I fixed the problem.
Now that I've toggled "NX Mode" on in my BIOS, I'm back to full AMD-V virtualization.
I don't remember seeing this option, prior to installing my Ryzen7. It's hard to find this setting documented anywhere in the manual for this BIOS but I am certain that toggling it "off" disables AMD-v support.
If you want, I can toggle it "off" and re-post my logs.

The 64-bits tutorial has lots of other things that Windows tries to use Hyper-V, which does interfere with Virtualbox. Check your screenshots against the tutorial.

Though I have not studied it heavily, I believe, based on the logs you have posted,the NativeAPI listing comes from Hyper-V being enabled. If you see a guest having trouble running and see NativeAPI, then search the guest's vbox.log for the lines I quoted here: viewtopic.php?f=6&t=99157&p=481202#p480920. If they are present in the vbox.log, your host still has Hyper-V enabled, and Virtualbox will not work right. Disable Hyper-V (very often the 'bcdedit' command in an admin command prompt is the silver bullet, see '64-bits' for a few other things), and AMD-V should come back, NativeAPI will disappear, and the guest will start working again.

NX Mode probably relates to the NX or XD bit, for 'eXecute Disable". I understand it is a way to block certain portions of memory from being the source of executable code, so malware can't hide code in a bitmap then somehow force the execution parts of the CPU to go to the middle of the bitmap and run whatever it sees as code. NX is required if the host OS or guest OS want to use it, but it is not a reason for NativeAPI or the Hyper-V log lines. A guest more usually guru-meditates with a note in the log that NX/XD is not present if the guest wants NX/XD and the host either doesn't provide it or it is disabled in the guest's Virtualbox settings.

scottgus1 wrote:Though I have not studied it heavily, I believe, based on the logs you have posted,the NativeAPI listing comes from Hyper-V being enabled.

The VirtualBox source code confirms what you believe.