This blog explains why VMware Workstation runs slower on Windows 11 compared to Windows 10, focusing on changes like Hyper-V, VBS, and HVCI being enabled by default on modern CPUs. It explores why sharing hypervisors with native hardware causes performance issues, and why disabling Hyper-V restores full VMware performance. Step-by-step PowerShell scripts are provided to toggle Hyper-V on or off safely.
Here’s a single, safe PowerShell script you can run before installing VMware Workstation to fully get Hyper-V and friends out of the way on Windows 11 for best performance. You can grab the script on my GitHub repo: cloudmigrationhu/script/vmware-workstation-performance at main · attilamacskasy/cloudmigrationhu
The blog you’re reading, along with the code examples and future updates, are all created using AI assistance.
All done! I’ve created a script that also validates whether VMs are running natively. When working with GitHub Copilot, it’s important to guide the AI through troubleshooting basics – for example, the generated code initially struggled to locate vmrun.exe, and I had to refine it.
The smarter you are, the fewer Premium Requests you’ll end up spending – especially when using GPT-5 in GitHub Copilot. Understand the nuances behind prompt design and model behavior, because even the most capable model won’t save you from inefficient usage.
Being smart about how you structure your prompts helps avoid exhausting your request quota too quickly.
Why It Matters
Premium Requests are counted whenever you invoke advanced models or features beyond the default. For example:
- GitHub Copilot’s Pro plan gives you 300 Premium Requests/month, while Pro+ gives 1,500/month. Anything beyond that costs $0.04 per request, with some models consuming multiple requests per turn. GitHubReddit
- The Coding Agent in Copilot uses exactly one Premium Request per session, regardless of complexity. The GitHub Blog
As a blogger and content creator, I sometimes struggle to write articles knowing many people now turn to AI instead of reading blogs. Still, I believe it’s valuable to share ideas, because without understanding what to ask and why things happen, AI won’t solve your problems. You need to understand both the questions you ask and the answers you receive. The following section is entirely AI-generated. You can skip it unless you want to dive into the detailed explanation of this blog’s process.
Here’s the GPT-5 prompt I used to create the content that follows: “Write a blog article explaining why VMware Workstation shows compatibility issues on Windows 11. Cover what changed compared to Windows 10, why this behavior only appears on modern CPUs (and not older ones), why sharing hypervisors with the hardware layer leads to performance problems, and why users should disable Hyper-V to allow VMware Workstation direct access to native hardware – just like in Windows 10 – for the best performance.“
Why VMware Workstation Shows a Hyper-V Warning on Windows 11
If you’ve tried to install or run VMware Workstation Pro on a modern Windows 11 machine, you may have seen a message like this:
This situation didn’t really exist back in Windows 10 days—or at least not to this extent. So what changed? Why does this issue only seem to affect newer CPUs, and why is it often better to disable Hyper-V entirely when using VMware Workstation? Let’s break it down.
What Changed in Windows 11
On Windows 10, Hyper-V was a feature you could enable manually. If it was off, VMware Workstation or VirtualBox had full access to hardware-assisted virtualization (Intel VT-x or AMD-V).
With Windows 11, Microsoft shifted towards Virtualization-Based Security (VBS) and Hypervisor-Protected Code Integrity (HVCI) being turned on by default—especially on newer hardware that passes modern security baselines. These features rely on Hyper-V under the hood, even if you never explicitly installed the Hyper-V role. That means:
- Even if you never used Hyper-V, Windows 11 might have it silently running to enforce security isolation.
- VMware Workstation now has to compete with Hyper-V for virtualization access.
Why This Affects Only Modern CPUs
On older CPUs, many of these security features simply aren’t supported. For example:
- VBS/HVCI require hardware-assisted virtualization and specific CPU extensions (Second Level Address Translation / SLAT, Mode-Based Execution Control, etc.).
- If your CPU doesn’t support those, Windows 11 doesn’t enable VBS/Hyper-V-lite in the background.
That’s why you don’t see this problem on older Intel Core i5/i7 or AMD FX CPUs: Windows 11 can’t enforce these modern security features, so it doesn’t run Hyper-V by default. On modern processors like AMD Ryzen 3000/5000 or Intel 8th gen and later, these features are present and automatically used.
Why Sharing Hypervisors Is a Bad Idea
VMware Workstation and Hyper-V are both type-2 hypervisors when running on Windows client. But under the hood, both want to be as close to the bare-metal CPU as possible.
When Windows forces VMware to run on top of Hyper-V (via the Windows Hypervisor Platform), performance suffers:
- Nested hypervisor layers add overhead.
- Certain instructions are emulated instead of being executed natively.
- Features like PCI passthrough, advanced networking, and GPU acceleration may not behave the same way.
In short: VMware Workstation loses the “direct-to-hardware” advantage it had in Windows 10.
Why You Should Disable Hyper-V for VMware Workstation
If your goal is performance and compatibility, especially for things like:
- Running older operating systems (DOS, Windows XP, legacy Linux distros)
- Using GPU passthrough
- Getting maximum I/O speed and responsiveness
…then you should disable Hyper-V entirely and let VMware Workstation talk directly to the hardware, just like in Windows 10. That means:
- Disable Hyper-V and related features in Windows Features:
- Hyper-V
- Virtual Machine Platform
- Windows Hypervisor Platform
- Windows Sandbox
- Disable VBS/HVCI if enabled via Windows Security → Device Security → Core Isolation.
- Reboot.
After this, VMware Workstation will run with native hardware access again, giving you back the performance you expect.
Conclusion
Windows 11 changed the virtualization game. Hyper-V is no longer just an optional feature—it’s quietly running to enforce security on modern CPUs. While that’s good for security, it creates friction for users who rely on VMware Workstation Pro or VirtualBox.
If your use case prioritizes maximum VM performance, hardware compatibility, and low overhead, the best option is to turn off Hyper-V and run VMware Workstation natively—just like you did in Windows 10.
For those who prefer Microsoft’s security features and occasionally spin up test VMs, leaving Hyper-V enabled might be fine. But for power users, developers, and IT pros who live inside VMware Workstation, disabling Hyper-V is the clear path to smoother, faster virtualization.
