> i also read that in non CPL0 mode there will be issues with performance...
I've been assiduously avoiding running in ULM mode because I've seen so many posts about substantial performance degradation when running that way.
It's too bad that after all this time this is still apparently the case. One would almost suspect Microsoft of not wanting to improve performance here... :-)
> as to the question why a win 11 vm with a virtual tpm is sooooo slow for suspend and snapshot.
I have a newer system (AMD Ryzen 7950X3D / X870E / all M.2 SSD) and a Guest with a Virtual TPM. Using the Workstation 17.6.4 task "VM / Power / Suspend Guest" is a little slow but not unbearably so. Maybe about 30 seconds for suspend and 20 seconds for resume.
Although my expectations may have been set from my last system where it took even longer. That system was probably about half as fast CPU wise and used some SATA attached SSDs. It was probably twice as slow to suspend (but I don't have any measurements now).
It's not clear to me why it can take as long as it does since the Windows 11 Host reports low CPU and Disk utilization during the suspend. So one would think it isn't being limited by those. (Or maybe it's only using one core/thread ??).
And raw memory read speed on my system would seem to be about 70 GB/second, at least according to AIDA64's cache and memory benchmark.
Original Message:
Sent: Aug 14, 2025 01:11 AM
From: Marc Antheunis
Subject: Disabling Hyper-V hypervisor on Windows 11 Pro host (to get VMWare 17's CPL0 vs. ULM monitor mode)
well i'm not sure how to interpret your comment... and i don't understand the reference to the 3rd party? do you consider win 11 a 3rd party?
So are you stating that running your vm in workstation 17.6.4 on a windows 11 pro host will not be different in terms of performance if it either runs in CPL0 or UML monitor mode? (i don't need for nested virtualization)
the whole reason for asking is that i had to tweak win 11 settings on my previous host, but that one runned the first win 11 iterations at that time...
AND the 17.6.4 installer warns about not being able to 'run native'(?) and therefore the installer wants to install the hyper-v subsystem
i also read that in non CPL0 mode there will be issues with performance
it would be helpfull if broadcom would publish a clear article on this, the knowledge base article the 17.6.4 installer refers to still talks about windows 10...
so i'de really would like to get a clear picture of this
as to the question why a win 11 vm with a virtual tpm is sooooo slow for suspend and snapshot...
thx for your insights
Original Message:
Sent: Aug 13, 2025 05:17 AM
From: RaSystemlord
Subject: Disabling Hyper-V hypervisor on Windows 11 Pro host (to get VMWare 17's CPL0 vs. ULM monitor mode)
Not sure what you are referring to?
VMware does run with default Windows 11 24H2 with all its default security measures on. Turning them off, doesn't *probably* really help. If you have installed something 3rd Party - then it is up to you to know what you did (or rather the 3rd Party company to explain what they do) - I understand that might be difficult to know.
I'm running VMware 17.5.2 all the time with default Windows 11 installation - with rather complex 3 VM setups and OpenGL and many different VMs (including Linux) - it works how it works. Win 11 is slow or very slow compared to Linux, but what can you do, if your applications are in Windows.
BUT if you are talking about nested virtualization - running virtualization in a VM - then you need to do all that.
Perhaps some of these Forum posts are confusing because they don't really explain WHY you are doing what you do.
Original Message:
Sent: Aug 13, 2025 05:01 AM
From: Marc Antheunis
Subject: Disabling Hyper-V hypervisor on Windows 11 Pro host (to get VMWare 17's CPL0 vs. ULM monitor mode)
i don't get it why the installer can't do the changes in order to be able to run natively... been trying to install for the last hour or so, this is a real pita.... also rather annoying that you have to turn off all kinds of security measures in order to run on the native vmware hypervisor
that said: my win 11 vm on win 11 host runs slow in suspend or auto snapshot, would that be faster running in ULM instead of CPL0?
Original Message:
Sent: Oct 03, 2023 06:38 AM
From: svenmerget
Subject: Disabling Hyper-V hypervisor on Windows 11 Pro host (to get VMWare 17's CPL0 vs. ULM monitor mode)
I had a very hard time getting rid of Hyper-V in my setup, on a Windows 11 Pro host. The "normal" steps I found all over the web weren't enough! Web sleuthing finally got me what I needed, and for posterity and future searchers I want to document what I did to achieve the coveted CPL0 monitor mode and improved VMWare virtualization performance under Win11.
So, what's going on with this OS that creates this new problem for Type 2 (hosted) hypervisors like VMWare Player/Workstation or VirtualBox? Windows 11 Pro, by default, doesn't have the Hyper-V features enabled (to actually run Hyper-V guests), but it (like Windows 11 Home, btw) does use the Hyper-V hypervisor for certain new "Virtualization-Based Security" (VBS) features. These include Device Guard, Credential Guard, and core (memory) isolation. Basically, with VBS the entire host operating system is actually not running as the host at all, it's running as a Hyper-V guest on top of the Hyper-V platform. This has some detrimental performance impact (mostly unnoticeable in normal use, except in gaming), but the advantage is that with the OS running as a "guest," with all hardware access having to cross the virtualization boundary, all kinds of additional security features become possible to prevent/mitigate modern attack vectors. Microsoft deems these protections to outweigh the performance hit, so as of 22H1 or 22H2 update, memory integrity protection, Device Guard, and Credential Guard are enabled by default on a new OS install, if the EFI settings have the CPU virtualization capabilities (VT-d, etc.) enabled. An existing install that's upgraded to 22H? will honor the existing settings btw.
OK, so what's the problem? It's actually not a problem at all, in a way, at least not since Workstation/Player 17 I believe, which introduces "play nice with Hyper-V" capability. If the Hyper-V hypervisor is active on the system, VMWare's product sets aside its own virtualization platform and uses the Hyper-V APIs to create the virtualized environment on which to run a guest. In a way, Hyper-V is running the virtual "hardware" for VMWare, while VMWare provides some of the value-added features like USB capture, 3D-accelerated graphics, etc. Same goes for VirtualBox's newer versions. The price to pay, though, is that this "referred" virtualization is slower than VMWare's own implementation would be, if only it could run in full-privilege mode, access VT-d directly, and operate its own virtualization stack.
The user/admin/operator of the Windows 11 host must make a decision as to which is more important: the new and enhanced bulletproofing against attacks provided by virtualization-based security features, plus the interoperability with Hyper-V (VMWare can coexist alongside Hyper-V features; one can run a Hyper-V guest and a VMWare guest at the same time!), and let's not forget that Hyper-V is necessary for the Sandbox/WSL feature...or ditching the Hyper-V platform altogether, and the extra security features, and the ability to run WSL, to get the best possible performance out of VMWare Player/Workstation.
If you're wondering for your Win11 host whether Workstation/Player 17 is running its own virtualization stack or not, first take a look at System Information app (search for it in Start menu). The System Summary page has an entry near the bottom of the list named "Virtualization-based Security". As long as that doesn't say "Not enabled", the Hyper-V hypervisor is pulling the strings, and the host OS you're looking at is actually a well-disguised guest OS. To see what VMWare has to say on the subject of current state, run any VM and take a look at the VMWare.log file that gets put alongside the VMX and other files for the VM. Search for "Monitor Mode:" and see the value after the colon. If the value is "CPL0", the VMWare engine is running. If the value is "UML", the slower Hyper-V API is in use.
OK, so let's say you've decided to go ahead and remove the hypervisor and let the host OS run without virtualization. Here is a sequence of actions to take. Some people seem to have luck with the first set, but if the first set is not enough, I've also got the final silver bullet that will definitely get that VBS value in System Information to change to "Not enabled," and VMWare (or VirtualBox) to be able to run with full hardware access and its own engine.
Phase 1:
- In Start menu search for "core isolation" to find the Core isolation page in Settings app. Turn off the Memory integrity protection, which will also disable the Kernel-mode Hardware-enforced Stack Protection. If Windows wants to restart, tell it "not yet" because there're some features to turn off, first.
- In Start menu search for "windows features" to find and open the Windows Features control panel. Turn off Hyper-V and all its subfeatures, and also Windows Hypervisor Platform, Virtual Machine Platform, and Windows Sandbox. The OS should ask to restart, let it.
Some people seem to succeed by doing just that. Check System Information. Is the VBS feature no longer in running stated? If not, let's try Phase 2, which throws several more kitchen sinks at the problem.
Phase 2:
- In Start menu search for "command" to find Command Prompt, right-click it, and run as administrator (elevated). It has to be elevated, otherwise the command you're about to type/paste won't work.
- Run command
bcdedit /set hypervisorlaunchtype off
- Close the command prompt window
- Hit Win+R to get the Run dialog, and run:
regedit
- After a UAC/elevation prompt, the Registry Editor opens. Right below the menu bar there's a texbox where you can paste this path and hit Enter:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\DeviceGuard
- The tree view below the textbox (on the left) should have taken you to the path you pasted, and the values in this registry node should be shown in the right pane. Find the value named "EnableVirtualizationBasedSecurity", double-click it to edit the value, and in the dialog box that appears type 0 in the "Value data" field, unless of course that's already the value that's set. Hit OK to save the change and close the Registry Editor.
- Hit Win+R again to get the Run dialog, and run:
gpedit.msc
- The Local Group Policy Editor should open. There's no convenient textbox to paste a path into, so you'll have to painfully expand nodes to find this path:
Computer Configuration -> Administrative Templates -> System -> Device Guard
- Find and double-click a setting in the right pane named "Turn On Virtualization Based Security", and in the dialog that appears, select the "Disabled" radio button, then OK button, and close the Local Group Policy Editor.
- Restart the OS and again check System Information to see if the VBS value has become "disabled."
Still not there? That's what happened to me, but there's one more thing to do, luckily assisted by a tool (script) provided by Microsoft, which in my experience finally takes that last step toward the nirvana of seeing the "disabled" value for VBS:
Phase 3:
There is a manual way to do this, and I found the instructions, but they're a bit scary. It involves using bcdedit to modify the boot configuration to apply a configuration change that sets a "DISABLE-LSA-ISO" option. Lots of opportunity for something to go wrong if the instructions I found are flawed, or if a mistake is made (typo, missed a command). So, I'm strongly recommending (and providing instructions for) the method that uses the Microsoft-provided script. I've tested it, it worked for me, and the same script provides a way to undo the whole thing later if desired, too. Power users are welcome to find the instructions I found on their own, or to simply open the script file and examine what it does for any manual implementation activities.
- Go to Download Device Guard and Credential Guard hardware readiness tool, provided by Microsoft to check Device Guard and Credential Guard capability, and to turn on/off the features. There's no setting anywhere in Settings app or control panel for this, and this "tool" is actually a PowerShell script, but it provides the necessary functionality. Find the Download button and click it, and your browser will download a ZIP archive.
- Find and extract the folder contained in the archive. Don't try to run the script from within the archive. If you're using Windows Explorer, it can make a ZIP archive look like just another folder, but it isn't. You need to drag out the "dgreadiness_v3.6" (version as of when I wrote this post) folder from the archive into a real folder, e.g. onto your Desktop.
- Search for "powershell" in Start menu to find Windows PowerShell, right-click it, and run as administrator (elevated). You must run it elevated or the script won't work.
- You need to change the current drive and directory to the one where the script is. If you're not command prompt savvy: type "C:" for example (no quotes) if the folder is on the C: drive, or "D:" if it's on the drive, etc., and hit Enter, which should change the active drive to the correct one; next, open the folder you extracted the script files into, copy the address from the address bar into the clipboard (highlight and Ctrl-C), then type the following command (replacing <path> with a Ctrl-V to paste the path you just copied), and hit Enter:
cd "<path>"
- The prompt in front of your blinking cursor should now match the folder where the script file is located, meaning your "current directory" is the correct one.
- Unless you know that you've already set this policy (power user), run this command next, to allow the script to be run:
Set-ExecutionPolicy Unrestricted
- You'll have to respond to a security prompt by typing "y" (if I remember correctly), possibly followed by Enter. It should then say it has successfully changed the execution policy.
- Now we can run the script. Type/paste (if the version number has changed since I posted this, adjust according to the filename of the .ps1 script file in the extracted folder):
DG_Readiness_Tool_v3.6.ps1 -Disable
- The script will do some stuff, and then you'll get to restart, and during restart you will get a full-screen prompt asking you to confirm you want to opt out of Device Guard and Credential Guard. Answer in the affirmative. I don't have precise instructions for the exact sequence of events and prompts/actions after running the script, because I ran it several days ago and didn't document what I saw.
- Once Windows has restarted with these features "opted out of," fire up System Information and check that VBS value again. For me, this was the final step that did the job, and when I ran a VMWare Workstation VM, it gave me the coveted Monitor Mode value of "CPL0"!
- By the way, for the sake of security, you might want to change the PowerShell script execution policy back to the more restrictive default one after these steps. If so, launch Windows PowerShell again, as administrator, and execute:
Set-ExecutionPolicy Default
I hope somebody finds this long writeup useful, either while searching this forum, or maybe when finding this post via a web search someday. It's based on what I documented during 2 days of web searches and frustration, and maybe it will save someone some headaches and time.