Skip to main content

💡 The CML VM Fix: Solving My VT-x/EPT Problem

💡 The Complete Fix: CML VT-x/EPT Error Solved 🛠️

I battled the persistent error: "Virtualized Intel VT-x/EPT is not supported on this platform" while installing CML (Cisco Modeling Labs) on VMware. This problem occurs because the Windows host locks the CPU's hardware virtualization features (VT-x/EPT) that CML needs to run its internal network nodes.

I discovered that fixing this requires aggressively disabling Virtualization-based security (VBS) and HVCI across multiple system layers.

Here is the definitive, comprehensive guide covering every step necessary to solve this issue.


Step 1: The Quick Fix (Disable Nested VT-x in VMware)

I found that telling VMware to hide the feature initially allowed the CML VM to boot, but it failed later when trying to run network nodes. This must be reversed later, but it is an important diagnostic step.

  1. Power off the CML VM.
  2. Go to SettingsProcessors.
  3. Ensure the box for Virtualize Intel VT-x/EPT or AMD-V/RVI is unchecked.
  4. Click OK to save the settings.

Step 2: Aggressive Windows Host Cleanup (The VBS Lock)

The primary cause is Virtualization-based security (VBS) running in Windows, often enforced by Hypervisor-enforced Code Integrity (HVCI), Docker, or Secure Boot. I had to disable these using powerful commands.

A. Disable Conflicting Windows Features

I confirmed the software using the hypervisor was off.

  1. Press Windows Key + R, type optionalfeatures, and press Enter.
  2. Ensure these boxes are unchecked:
    • Hyper-V
    • Virtual Machine Platform
    • Windows Hypervisor Platform

B. Disable Docker (The Key Conflict)

Docker often runs its own hypervisor instance, locking VT-x. I had to completely uninstall it.

  1. Quit Docker Desktop from the system tray.
  2. Uninstall Docker Desktop via Programs and Features.
  3. Open Command Prompt (Admin) and run:
    wsl --shutdown

C. Disable VBS/HVCI via PowerShell

I used the registry to explicitly disable the security features causing the conflict.

  1. Open PowerShell (Admin).
  2. Run the following commands:
    Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" -Name Enabled -Value 0
    bcdedit /set hypervisorlaunchtype off

D. Use the Readiness Tool (The Final Fix)

When VBS persisted, I used the Microsoft tool to forcefully clear the security flags.

  1. Download the DG_Readiness_Tool.ps1 script.
  2. Open Command Prompt (Admin).
  3. Run the script command, replacing the path:
    powershell -ExecutionPolicy Bypass -File .\DG_Readiness_Tool.ps1 -Disable -AutoReboot
  4. Crucially, confirm the security disable prompt during the boot process.

E. Suspend BitLocker

I learned that BitLocker complicates this process. I ran this command before the final restart to avoid interference:

manage-bde -protectors -disable C: -rebootcount 1

Step 3: Final Verification and Re-enabling VT-x

After the tool ran and the system rebooted, VBS was finally disabled.

  1. Verify VBS is Off: Check System Information (msinfo32). Virtualization-based security must show Not enabled.
  2. Re-enable Nested VT-x: Go back to the CML VM SettingsProcessors. CHECK the box for Virtualize Intel VT-x/EPT or AMD-V/RVI.

The CML VM booted without the error and successfully run its virtual network devices.

Comments

Popular posts from this blog

Telecoms: ePSK - Multiple Pre-Shared Keys

Originally posted on the Cambium Community Networks Just in case you missed it cnMaestro Version 2.2.1 (Cloud and On-Premise), brings us a great new feature called ePSK. If you’re not familiar with ePSK it’s maybe because Cambium are too modest to toot their own trumpet so I’m going to do it for them. In short ePSK gives each user a unique PSK (pre-shared key) when using WPA2-Personal, for me to explain why this is such a useful feature let me first explain the problem with using a shared PSK across the whole WLAN. When a wireless client connects to an AP it completes a 4-Way handshake, this generates the encryption keys used to encrypt wireless traffic. For the 4-way handshake to work it is a requirement that both the client and AP know the passphrase, however the passphrase is never transmitted over the air thereby making this exchange reasonably secure. But what happens when a 3rd party already knows the passphrase? It means they just need to capture the 4-way handshake to gener...

7 Apps You Should Delete Right Now And Why the Law Makes Them Dangerous

  There is a conversation happening in security research circles, government agencies, and regulatory bodies around the world, and most Papua New Guineans are not part of it. It concerns a small group of applications that sit on hundreds of millions of Android and iOS devices, including many in PNG, quietly running in the background, collecting data, and transmitting that data to servers governed by a legal system that has no obligation to protect you. In PNG, where mobile phones are the primary gateway to banking, communication, and identity, this risk is amplified. For many users, a smartphone is not just a device. It is their wallet, their ID, and their connection to essential services. This is not about a theoretical vulnerability or an obscure technical exploit. It is about the intersection of consumer software and national law, specifically the legal architecture that governs what foreign technology companies must do when their government asks for your data. The Legal Foun...