π‘ 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.
- Power off the CML VM.
- Go to Settings → Processors.
- Ensure the box for Virtualize Intel VT-x/EPT or AMD-V/RVI is unchecked.
- 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.
- Press Windows Key + R, type
optionalfeatures, and press Enter. - 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.
- Quit Docker Desktop from the system tray.
- Uninstall Docker Desktop via Programs and Features.
- 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.
- Open PowerShell (Admin).
- 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.
- Download the DG_Readiness_Tool.ps1 script.
- Open Command Prompt (Admin).
- Run the script command, replacing the path:
powershell -ExecutionPolicy Bypass -File .\DG_Readiness_Tool.ps1 -Disable -AutoReboot - 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.
- Verify VBS is Off: Check System Information (
msinfo32). Virtualization-based security must show Not enabled. - Re-enable Nested VT-x: Go back to the CML VM Settings → Processors. 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
Post a Comment