That error message is Docker Desktop's way of saying the virtual machine layer it depends on never switched on at the hardware level. On Windows the culprits are usually Hyper-V, Windows Hypervisor Platform, or Virtual Machine Platform being disabled, or hardware-assisted virtualization being off in firmware; on macOS it is almost always a missing Apple silicon or Intel VT-x requirement, or a hypervisor held by another application. You can't fix it from inside Docker Desktop. You fix it in Windows Features, in firmware, or in the configuration of the software that is already holding the hypervisor.
This guide walks through the five real checkpoints Docker Desktop applies, in the order it applies them, so you know what to fix and what not to touch. It also names what the message gets right, what it gets wrong, and which of the "just enable virtualization" advice floating around will actually break Docker if you follow it.
Every Docker Desktop Installation Runs a Preflight Hypervisor Test
When Docker Desktop launches, it doesn't go straight to containers. It first asks the operating system whether a hardware hypervisor can be created on this machine, and if the answer is no on either branch, it shows the virtualization error before the tray icon ever appears. On Windows, the underlying engine needs either the Hyper-V hypervisor (Windows Pro, Enterprise, and Education) or the Windows Subsystem for Linux 2 architecture that calls into the Windows Hypervisor Platform. On macOS, Docker Desktop relies on Apple's Hypervisor.framework, which itself requires Apple silicon or an Intel CPU with VT-x enabled.
The preflight is a capability probe, not a performance test. It checks for CPU instruction support, firmware enablement, the presence of the relevant Windows feature bits, and whether an existing hypervisor is reachable to the calling process. A machine with an old Intel Core 2 Duo and a modern Windows 11 install will fail even if every box in Windows Features is ticked, because the CPU lacks the instruction set.
Virtualization is the hardware switch; the hypervisor is the software layer that uses it. The error conflates the two because the diagnostic script can't distinguish "off in firmware" from "not supported by CPU" from "blocked by another hypervisor" without manual inspection. That conflation is why the IT admin line appears: in managed environments, the firmware toggle is typically locked behind BIOS passwords that only IT holds.
The reference date for behaviour described here is Docker Desktop's release line as of November 2026; exact dialog wording can shift between minor versions, so treat specific on-screen text as illustrative and the feature names in Settings and Windows Features as authoritative. Apple's Hypervisor.framework documentation, Microsoft's Hyper-V architecture page, and Docker's own troubleshooting guide each cover one third of the picture; none of them reconciles the three.
Check Task Manager First Before Any Reboot Into Firmware
The fastest way to know whether the problem is firmware or software is Task Manager's Performance tab. Click CPU, look at the lower-right corner, and read the line labelled Virtualization. If it says "Enabled", the hardware is fine and the fault is in Windows features or in another hypervisor. If it says "Disabled", you have to go into firmware to switch it on. A third state, "Not supported", means the CPU doesn't offer it and no software change helps.
On macOS, the equivalent is to open Terminal and run sysctl kern.hv_support. A returned value of 1 means Hypervisor.framework is available to Docker Desktop; 0 means it isn't, which usually tracks back to an older Intel Mac or to a macOS virtualisation setting that a management profile has disabled. This single command saves a trip through Support diagnostics.
If Task Manager shows Virtualization: Disabled, the fix is a reboot into firmware settings. On most Dell, HP, and Lenovo machines the key is F2, F10, or Del on the manufacturer splash screen. Look under Advanced, CPU Configuration, or Security for a setting labelled Intel Virtualization Technology, Intel VT-x, AMD-V, or SVM Mode. Enable it, save and exit. Some laptops require you to also disable "VT-d" restrictions or enable "Trusted Execution" before the toggle is honoured.
One failure case worth knowing: enabling VT-x in firmware and disabling Intel TXT from the same screen will reset the BIOS to defaults on some Dell Latitude models, which silently reverts virtualization. If Task Manager reverts to Disabled after a reboot, suspect a firmware reset or a management agent overwriting the setting. Confirm on the manufacturer's support site rather than guessing.
The Windows Features You Enable Decide What Docker Can Use
On Windows, Docker Desktop can run on three distinct backends, and each requires a different combination of Windows Features. Ticking the wrong one wastes a reboot or, worse, breaks a working configuration.
| Backend | Required Windows features | Windows edition | Notes |
|---|---|---|---|
| Hyper-V (Windows containers) | Hyper-V, Containers | Pro, Enterprise, Education | Not available on Home |
| WSL 2 (Linux containers) | Windows Subsystem for Linux, Virtual Machine Platform | Pro, Enterprise, Education, Home | Docker Desktop's default on supported builds |
| Windows Hypervisor Platform | Windows Hypervisor Platform, Virtual Machine Platform | Pro, Enterprise, Education, Home | Needed for third-party hypervisors alongside Docker |
Open Turn Windows features on or off from the Start menu search, tick the required checkboxes, and click OK. Windows will prompt for a restart. WSL 2 requires the Windows Subsystem for Linux feature plus the Virtual Machine Platform, and Docker Desktop's own installer also wants the "Containers" feature when Windows container mode is selected.
Here's the failure most guides skip: enabling Hyper-V on a machine you also want to use with VMware Workstation or VirtualBox can break those products unless they're on a version that supports the Windows Hypervisor Platform. VMware Workstation 15.5.5 and later and VirtualBox 6.0 and later can coexist with Hyper-V, but only after you enable the platform features and update the products. If you're on older versions, you'll trade one broken tool for another.
Home edition is a hard boundary. Hyper-V isn't shipped there, so Windows container mode is permanently unavailable on Home; the only workable Docker Desktop configuration is WSL 2 with Linux containers. If a blog post tells Home users to enable Hyper-V, it's wrong for that edition.
Firmware, WSL 2 and Conflicting Hypervisors Each Fail Differently
Docker Desktop's error appears in four genuinely different situations, and the fix differs each time. Treat the message as a flag, then match the case.
Firmware virtualization is off. Task Manager shows Virtualization: Disabled. Fix in BIOS/UEFI as above. Windows features missing. Task Manager shows Enabled, but Virtual Machine Platform or Hyper-V isn't ticked. Fix in Turn Windows features on or off. WSL 2 not installed or not default. Docker Desktop shows a separate WSL error in modern versions, but some builds fall through to the virtualization message. Run wsl --status in PowerShell to check the default version; if it reports version 1, run wsl --set-default-version 2. Another hypervisor is holding the CPU. VirtualBox, VMware, or a corporate endpoint protection agent can claim the hypervisor extension, and Docker Desktop reports the same virtualization failure even though Task Manager shows Enabled.
The fourth case is the one to be careful about. Corporate laptops often have Credential Guard, Device Guard, or a managed Virtualization-Based Security (VBS) configuration that occupies the hypervisor. The error message you see is accurate but the fix is not "enable virtualization" β it's to contact IT and ask them to either allow Docker Desktop as a sanctioned hypervisor under VBS or move the machine to a policy that permits it. Enabling firmware virtualisation in that situation can actually make the machine fail to boot if VBS is pinned, so raise a ticket first.
If you're told to disable VBS to fix Docker, push back. Microsoft's documentation for Windows 11 lists VBS as a defence-in-depth feature for credential isolation, and disabling it silently has security consequences. The right resolution is an IT policy that permits Docker Desktop under the existing VBS configuration.
A Five-Step Fix Sequence From Task Manager to Container Start
Use this sequence; each step rules out a layer before you touch the next.
1: Open Task Manager, click Performance, then CPU, and read the Virtualization line. If it says Disabled or Not supported, note that and continue to step 2. 2: Reboot into firmware (F2, F10, or Del on most laptops). Enable Intel VT-x, Intel Virtualization Technology, AMD-V, or SVM Mode. Save and exit. 3: In Windows search, open Turn Windows features on or off. For WSL 2 Linux containers on any edition, tick Windows Subsystem for Linux and Virtual Machine Platform. For Windows containers on Pro or above, also tick Hyper-V and Containers. Restart. 4: In PowerShell, run wsl --status and wsl --update. If the default version is 1, run wsl --set-default-version 2. If WSL reports a missing kernel, run wsl --install. 5: Launch Docker Desktop and wait for the whale icon to settle. If the error persists, open Docker Desktop's own troubleshoot screen and read the preflight log, which names the missing capability directly.
If step 5 still produces the virtualization error after all of the above, the remaining causes are corporate policy (VBS, Credential Guard, endpoint agents) or an installed hypervisor grabbing the extension. Both require IT to confirm what is holding it. Don't factory reset or disable VBS on your own initiative to force Docker Desktop to start.
A useful side check: run systeminfo in Command Prompt and scroll to the Hyper-V Requirements section at the bottom. If it says "A hypervisor has been detected. Features required for Hyper-V will not be displayed", something is already hypervising the machine and Docker should be able to attach β which shifts the fault to Windows features, not firmware.
Mac Users Have Fewer Levers and Should Know Them
On macOS the equivalent of the Windows features checklist is much shorter, but the failure cases are different. Apple silicon Macs (M1 and later) support Hypervisor.framework unconditionally; every Mac sold since late 2020 meets Docker Desktop's hardware requirement out of the box. Intel Macs need VT-x, which Apple enabled by default on Macs from 2006 onward, so a firmware failure is almost unheard of unless the Mac is managed.
If Docker Desktop throws the virtualization error on a Mac, the most likely cause is a conflicting hypervisor. Older Docker Desktop installs (before 4.x) shipped a bundled HyperKit, and residual kexts or a stale VirtualBox installation can block the modern Hypervisor.framework path. Quitting VirtualBox, stopping any running com.docker.vmnetd helper, and reinstalling Docker Desktop from a clean DMG usually clears it.
Managed Macs on Jamf or an MDM can have Hypervisor.framework restricted by configuration profile. Ask IT to confirm that "Allow Hypervisor" is enabled for your device profile. This is the Mac equivalents of the corporate VBS case on Windows and is equally invisible from inside Docker Desktop.
Apple silicon users also occasionally hit the error when running Docker Desktop under Rosetta; the Intel build of Docker Desktop does not see Hypervisor.framework on an Apple silicon host. Confirm you're running the arm64 build from Docker's own site, not from a Rosetta-translated installer. The launch experience tells you which: the arm64 build shows the Apple silicon icon in the menu bar.
Numbers That Make the Trade-Off Visible Before You Enable Anything
Firmware and Windows-feature enabling is a one-time change, but it has measurable costs. According to Microsoft's Hyper-V performance guidance, the hypervisor layer imposes a small per-I/O cost compared with native execution; typical numbers cited in Microsoft's own benchmarking are in the low single-digit percentage on throughput for workloads that aren't virtio-aware. That small cost is why CI runners use bare metal for the most throughput-sensitive batch jobs rather than Docker Desktop on laptops.
The bigger cost is RAM. Docker Desktop's default memory allocation on Windows through WSL 2 is half of total system RAM, and it can rise to that cap during a heavy docker build. On a 16 GB laptop that's 8 GB committed to the WSL 2 VM the moment Docker Desktop starts, whether or not you're running containers. Reducing the cap to 4 GB in Settings β Resources β Advanced is the single biggest performance change most laptop users make after getting past the virtualization error.
Reboot time after a Windows feature change is typically one restart, two at worst. If you tick Hyper-V, Windows often requests a second restart to finish the hypervisor configuration. Budget 10β15 minutes end to end for the first-time fix on a laptop with SSD storage, compared with two minutes for a firmware-only fix. That difference matters when the same laptop is used for CI work between meetings.
WSL 2 has its own memory behaviour worth knowing before you blame the hypervisor. Since Windows 11 22H2, WSL 2 releases cached memory back to Windows after a configurable idle period, default 1 minute, but the release is not immediate. Users who run Docker Desktop for a full working day on a 16 GB laptop and see Windows itself starve will find the fix is in .wslconfig (setting autoMemoryReclaim=gradual or dropcache), not in the virtualization settings.
Settings and Logs Tell You Exactly What Failed
Docker Desktop's tray icon opens a menu with a Troubleshoot option. Inside is a "Start Docker Desktop" button with a diagnostics view that records the preflight test line by line. On Windows this file is placed under %LOCALAPPDATA%\Docker\log\vm\ and there is a separate host log in %LOCALAPPDATA%\Docker\log\host. Search the host log for "virtualization" and the log will name the specific capability that failed: "VT-x not supported", "Hyper-V not installed", or "another hypervisor holds the extension".
On macOS the equivalent logs sit under ~/Library/Containers/com.docker.docker/Data/log/. The vm log is where Hypervisor.framework failures show up; the host log records WSL-like feature detections. Reading those files once is worth hours of forum scrolling.
Docker Desktop's Settings β General tab has a "Use Virtualization framework" checkbox in recent releases. On Apple silicon this is on by default and should stay on. On Intel Macs it can be toggled and, if you're on an older macOS, turning it on can fix a hypervisor detection failure that the default HyperKit path doesn't catch. This is a version-specific difference most guides skip.
If your Windows laptop is on 8 GB of RAM, expect Docker Desktop to run but to be slow with multi-container stacks. That's a capacity limit, not a virtualization failure. Once Docker starts, memory pressure on the host OS is the next problem to solve, typically by keeping only one stack up at a time or moving to a 16 GB minimum for development laptops in 2026.
Why the IT Admin Line Is Often Accurate and Sometimes a Red Herring
In about half the cases where users paste this error into a forum, the machine is corporate-managed. Endpoint policy on Windows can block firmware virtualization changes, disable the Virtual Machine Platform feature at policy level, or enforce VBS/Device Guard in ways that conflict with third-party hypervisors. The dialog's IT admin line exists precisely for that population. If your machine is managed, raising a ticket with the Docker Desktop version number and the exact preflight log line is faster than DIY fixes.
For everyone else, the IT admin line is misdirecting. The plaintiff user is the IT admin. Nothing in the fix requires a credential beyond local administrator, and the diagnostic steps β Task Manager, Windows Features, BIOS β are all within a home user's reach. Treat the message as a label for the failure class, not as an instruction to defer.
The error text is also imprecise in one important respect: "virtualization support wasn't detected" suggests a hardware detection failure, but on Windows the most common cause is a missing Windows feature rather than anything hardware-related. Users who follow the message to firmware first often enable VT-x that was already on. Checking Task Manager first, as advised above, saves that wasted reboot.
Version drift is worth flagging. Docker Desktop 4.30 and later tightened the preflight test and now surfaces a separate WSL-related error message when the WSL 2 kernel is missing, rather than falling through to the generic virtualization message. Users on 4.25 or older may still see the generic error in WSL 2 scenarios; upgrading Docker Desktop first, then re-running the fix sequence, is often the cleanest single step. Confirm the current version on Docker's own release notes page, since release numbering changes without notice.
FAQ
Does enabling PowerShell's "VirtualMachinePlatform" need a reboot?
Yes. Enabling any Windows feature that participates in the hypervisor stack, including Virtual Machine Platform, Hyper-V, and Windows Subsystem for Linux, requires a restart to take effect; Docker Desktop will continue to show the virtualization error until you restart, even if the feature was enabled successfully.
Can I run Docker Desktop on Windows 11 Home edition?
Yes, but only in WSL 2 Linux-container mode. Hyper-V is not shipped in Home, so Windows container mode is unavailable on that edition regardless of hardware. Enabling WSL 2 and Virtual Machine Platform is the only supported combination on Home, and Task Manager will show Virtualization: Enabled if the firmware switch is on.
What if Task Manager shows Virtualization: Enabled but Docker still fails?
That narrows the fault to Windows features or a competing hypervisor. Check Turn Windows features on or off for Virtual Machine Platform and Hyper-V, run wsl --status to confirm the default WSL version is 2, and look at Docker Desktop's host log under %LOCALAPPDATA%\Docker\log\host. Corporate VBS/Device Guard is the most common remaining blocker on managed laptops.
Is disabling VBS an acceptable fix?
No. Virtualization-Based Security protects credential isolation and code-integrity features on Windows 11 and is enabled by default on many OEM builds. Turning it off to let Docker Desktop launch is a security downgrade, and Microsoft's own documentation lists it as a protected capability. On managed devices, ask IT to permit Docker Desktop under VBS rather than removing VBS.
How long does the full fix take end to end?
For a home laptop with a modern SSD and no corporate policy, expect 10β15 minutes including the Windows feature restart and a single reboot. For a managed machine where IT must approve the Docker Desktop hypervisor under VBS or lift a firmware policy, allow one to three business days for the ticket cycle.
Does Docker Desktop use Hyper-V or WSL 2 by default in 2026?
On Windows, Docker Desktop defaults to WSL 2 for Linux containers and offers Hyper-V for Windows containers on Pro, Enterprise, and Education editions. On macOS, Docker Desktop uses Apple's Hypervisor.framework on Apple silicon and on Intel Macs with VT-x, replacing the older HyperKit approach used in pre-4.x releases.
What's the difference between virtualization and a hypervisor?
Virtualization is the CPU-level capability (VT-x on Intel, AMD-V on AMD, Hypervisor.framework on Apple silicon) that lets a program run virtual machines at near-native speed. A hypervisor is the software layer that uses virtualization β Hyper-V, WSL 2's lightweight utility VM, or Apple's Hypervisor.framework. Docker Desktop needs both, which is why the error can appear even when firmware virtualization is already on.