Your VirtualBox VM still boots and runs, but it feels sluggish, and there’s a small green turtle sitting in the status bar at the bottom of the VM window. It’s easy to ignore. You shouldn’t.
That turtle is a deliberate warning. VirtualBox is telling you the VM is not running on native hardware virtualization. Instead of owning Intel VT-x or AMD-V directly, it’s running on top of the Windows hypervisor — the same Hyper-V execution layer that WSL2 and Docker Desktop use — and that extra layer is what’s slowing everything down.
The fix is the same family of switches you’d use for the outright VERR_VMX_NO_VMX error, but
the symptom is gentler: instead of refusing to start, VirtualBox quietly drops to the slow path
and flags it with the turtle. Here’s what’s happening and how to get native speed back.
What the green turtle actually means
VirtualBox runs VMs in one of two modes on Windows. In native mode, it grabs the CPU’s VT-x (Intel) or AMD-V (AMD) extensions and talks to the processor directly — fast, the way it’s meant to work. In Hyper-V execution mode, the Windows hypervisor already owns those extensions, so VirtualBox sits on top of the Windows Hypervisor Platform API and runs the VM as a guest of Hyper-V.
The second mode works, but there’s a performance cost because virtualization calls pass through an additional layer. The turtle icon appears whenever VirtualBox detects it’s in that fallback mode. No turtle means native VT-x; turtle means Hyper-V backend.
Confirm the turtle is really the hypervisor
Before changing anything, confirm what mode you’re in so you don’t chase the wrong fix.
Open Task Manager → Performance → CPU and look at the Virtualization line. If it says Enabled, VT-x is on at the hardware level — so the turtle is about who owns it, not whether it’s available. That points squarely at the Windows hypervisor.
You can also check from the VM log or the command line. The boot setting that controls the hypervisor is the clearest signal:
bcdedit /enum {current}Look for the hypervisorlaunchtype line. Auto means the Windows hypervisor will start at
boot and take VT-x — that’s your turtle. Off means it won’t, and VirtualBox should be
running native.
Why the hypervisor is running (it’s not just Hyper-V)
The most common assumption is “I never turned Hyper-V on, so this can’t be Hyper-V.” But the Hyper-V checkbox is only one of several features that start the Windows hypervisor. Any of these will do it:
Windows features that start the hypervisor and trigger the turtle
| Hyper-V | Enabled directly, or pulled in by Docker Desktop / Visual Studio workloads |
|---|---|
| Memory Integrity (Core Isolation) | On by default on many Windows 11 machines; uses VBS |
| Virtual Machine Platform | Required by WSL2 |
| Windows Subsystem for Linux (WSL2) | Pulls in Virtual Machine Platform + hypervisor |
| Windows Sandbox | Runs on Hyper-V isolation |
| Credential Guard | VBS-based, common on enterprise/domain-joined machines |
Memory Integrity is the sneaky one. It ships on by default on a lot of new Windows 11 laptops, and Windows updates have a habit of re-enabling it after you turn it off. If VirtualBox was fast last month and the turtle showed up after a Windows update, check Memory Integrity first.
Fix it: free VT-x for native VirtualBox
Work down this list. Reboot after each change that asks for one, then start your VM and check whether the turtle is gone. You can often stop partway once it disappears.
1. Turn off Memory Integrity. Windows Security → Device security → Core isolation details → switch Memory integrity Off, then reboot. This alone clears the turtle on a lot of machines.
2. Disable Hyper-V. Run optionalfeatures, clear the Hyper-V boxes, reboot. Or from an
elevated PowerShell prompt:
Disable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All3. Remove Virtual Machine Platform and WSL if you don’t need WSL2:
Disable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform
Disable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux4. Force the hypervisor off. If the turtle is still there after the features are gone,
something is leaving the boot setting on Auto. Set it off explicitly:
bcdedit /set hypervisorlaunchtype offReboot. After it comes back up, VirtualBox should own VT-x and run native — no turtle.
Steps to clear the turtle
- Confirm Virtualization shows Enabled in Task Manager
- Turn off Memory Integrity under Core Isolation, reboot
- Disable Hyper-V via optionalfeatures, reboot
- Remove Virtual Machine Platform / WSL if not needed
- Set hypervisorlaunchtype off and reboot
- Re-enable everything later with hypervisorlaunchtype auto
The other option: keep the turtle on purpose
You don’t have to fight it. If your day revolves around Docker Desktop or WSL2 and VirtualBox
is something you open occasionally, leaving the turtle in place is a reasonable call. The VM is
slower, but everything coexists and you never touch bcdedit.
VirtualBox 7.x improved this Hyper-V backend over the early 6.1 versions, so the penalty isn’t always as bad as it once was. For light VMs — a test box, a quick Linux install, something you don’t run benchmarks on — the turtle mode may be perfectly usable.
The decision is the same one you face with the VT-x error:
- VirtualBox is your main tool and you want speed — free VT-x by turning the Windows hypervisor off, accept that Docker/WSL2 stop until you turn it back on.
- You live in Docker/WSL2 and run VirtualBox rarely — keep the hypervisor on, accept the turtle, and make sure you’re on VirtualBox 7.x for the better backend.
There’s no setting that gives both stacks full hardware speed at the same time. One set of CPU extensions, one owner.
Confirm the fix worked
After your reboot, start the VM and check two things:
- The status bar. The green turtle should be gone. If it’s still there, the hypervisor is
still loading — recheck
bcdedit /enum {current}forhypervisorlaunchtype offand look for any feature you missed (Memory Integrity loves to come back). - Actual speed. Boot time and general responsiveness should jump. A VM that took a minute to reach the desktop in turtle mode usually does it in a fraction of that on native VT-x.
If the turtle is gone but performance is still poor, the bottleneck is something else — undersized VM memory, too few CPU cores, or slow disk. The VirtualBox VM running slow on Windows 11 guide walks through those settings. And if you’re juggling several VM tools on one box, the broader virtualization troubleshooting guides cover the conflicts that tend to recur.
Wrapping up
The green turtle isn’t a fault to debug — it’s VirtualBox flagging that it lost native VT-x to
the Windows hypervisor and fell back to the slower Hyper-V execution mode. Confirm
virtualization is enabled in Task Manager, then clear whatever is holding the hypervisor:
Memory Integrity, Hyper-V, Virtual Machine Platform, WSL2, and finally the
hypervisorlaunchtype boot switch.
Decide which stack matters more on this machine. If it’s VirtualBox, free VT-x and the turtle disappears. If it’s Docker or WSL2, leave the hypervisor running and let VirtualBox plod along in shared mode. Either way, the turtle has told you exactly what’s going on — now you know which switch changes it.
