在虚拟化这条路上，我见过太多用户在 BIOS 里把“启用虚拟化”的开关来回拨，重启进系统后虚拟机软件还是不给面子。要么弹“此主机支持 Intel VT-x，但该功能处于禁用状态”，要么提示“VT-x is not available”，明明设置看起来都对，就是跑不起来。今天这篇就把 Windows 开启 CPU 虚拟化和关闭 Hyper-V 这两件事从头到尾捋一遍，包括 BIOS 菜单在哪、系统里哪些开关该关、哪些隐藏功能会偷偷占用虚拟化，以及操作完怎么验证。适合刚接触虚拟机的初学者，也适合那些设置看起来全对但始终卡壳的老手。看完你基本能把自己遇到的“虚拟化失效”问题定位到具体环节。
1. 为什么 BIOS 里开了 VT-x，虚拟机还是提示“未开启”：Hyper-V 抢占虚拟化扩展的真相
1.1 一次典型的“翻车”现场
先说个最常见的场景。某开发者新装了 VMware Workstation，第一次新建虚拟机点启动，屏幕上直接来一句“此主机支持 Intel VT-x，但该功能处于禁用状态”。他进 BIOS 把虚拟化打开，保存重启，再开 VMware，一样的报错。于是他怀疑自己没保存成功，又进 BIOS 确认了三遍，选项确实是 Enabled。当时我也遇到过类似问题，一度以为是主板固件有 bug，后来才发现问题根本不在硬件层。
还有一位用户是用 VirtualBox 跑 Android 模拟器，一直提示“VT-x is not available”，他抓狂到把 CPU 驱动和系统补丁都更新了一遍，依旧无解。这些案例的共同点是：硬件层的虚拟化扩展其实已经打开了，但软件层有人抢先占住了它。
这里可以把 CPU 的虚拟化能力理解成一把备用钥匙。在这台电脑里有两个角色都想用它：一个是你装的那些第三方虚拟机软件，另一个是 Windows 自带的虚拟机监控程序。如果 Windows 这边的“管家”先把钥匙拿走了，第三方虚拟机软件自然只能在门外干瞪眼。这就是很多教程只让你“开 VT-x”却收不到效果的真正原因——除非你在系统层面把那个抢先占用的管家请走，否则硬件开关怎么拨都没用。
1.2 硬件虚拟化、Hypervisor、Hyper-V 三者到底什么关系
先把概念理顺。CPU 虚拟化扩展（Intel VT-x，AMD 平台则叫 SVM，有时也叫 AMD-V）是处理器提供的一种硬件能力，它让虚拟机可以高效使用 CPU 的硬件加速指令。没有它，虚拟机软件只能靠纯软件模拟来运行客户机，速度惨不忍睹。这是物理层面的开关，通常在 BIOS/UEFI 里设置。
Hypervisor 则是运行在硬件和操作系统之间的软件层，翻译过来叫虚拟机监控程序。Windows 自带的 Hyper-V 就是一个这样的监控程序。一旦 Hyper-V 启动，整个 Windows 实际上变成了跑在 hypervisor 之上的一个“根分区”，hypervisor 会直接接管 VT-x/SVM 这个硬件能力。
第三方虚拟机软件（VMware、VirtualBox）默认是自己在用户态直接读写 VT-x 的。当 hypervisor 已经占用硬件虚拟化时，双方都想用同一把钥匙，于是冲突就出现了。有的新版本第三方软件可以通过 Windows Hypervisor Platform 兼容层来绕开冲突，但代价是性能明显下降，而且嵌套虚拟化能力受限。所以，只要你想让虚拟机跑得又快又稳，“关闭 Hyper-V 相关功能 + 确保 hypervisor 不启动”几乎是绕不开的一步。
1.3 如何确认到底是谁占用了虚拟化扩展
如果你现在的状态是“任务管理器显示虚拟化已启用，但虚拟机软件还是提示不可用”，那大概率就是某个 hypervisor 正在运行。可以用下面三个方法快速确认：
- 任务管理器：按 Ctrl+Shift+Esc，切到“性能”选项卡，选 CPU，看右下角的“虚拟化”字段。它只能告诉你虚拟化扩展是否可用，不能告诉你有没有被占用。
- 系统信息：Win+R 输入 msinfo32，回车后在“系统摘要”最下方找“虚拟机监控程序”。如果显示“检测到一个虚拟机监控程序”，说明系统里确实有 hypervisor 正在运行，即便你什么都没建，它也在。
- Sysinternals 工具 Coreinfo：管理员身份运行 coreinfo -v，看“VT-x”那一行。如果是 * 表示虚拟化可用且没有被占用；如果是 - 表示被占用或不可用。这是判断占用来源比较准的手段，很多虚拟化异常问题靠它一眼定位。
注意，Hyper-V 功能勾选着但不代表 hypervisor 就一定在跑，而 msinfo32 检测到虚拟机监控程序则一定说明有功能或安全机制把它拉起来了。下面要做的，就是把“把它拉起来”的因素全部排掉。
2. 主板 BIOS 开启 CPU 虚拟化：按平台和机型的实际菜单位置
2.1 Intel 与 AMD 的开关名称对照
先说名称。Intel 平台的虚拟化开关最常见的叫法有：Intel Virtualization Technology、VT-x、VMX，有的主板 BIOS 里还会把 VT-d 单独列出来。VT-d 是给设备直通和 I/O 虚拟化用的，普通虚拟机场景不强制要求开，但对需要直通显卡或网卡的用户来说，顺手开开没坏处。
AMD 平台的开关通常叫 SVM Mode，全称 Secure Virtual Machine，有的固件里显示为“SVM 虚拟化”或“Secure Virtualization”。部分 AMD 主板上还有一个 IOMMU 选项，作用和 Intel 的 VT-d 类似。只要把 SVM 设为 Enabled，AMD 平台的 CPU 虚拟化就算打开了。
一个小提示：很多用户第一次进 BIOS 发现找不到这些选项，是因为 UEFI 主界面默认是简易模式(EZ Mode)，需要按 F7 或其他快捷键切到高级模式，再去找“Advanced”“CPU Configuration”“CPU Features”这类菜单。不同主板固件路径不一样，但大多都藏在这些分类下面。
2.2 常见消费级主板的通用路径参考
由于品牌固件差异很大，这里不逐个厂商列举，而是给你一套可以套用的查找逻辑。
开机后连续按 Del 或 F2 进 BIOS/UEFI，在高级模式里这样找：
- 找带“Advanced”或“Configuration”字样的菜单，进入 CPU 相关子菜单。
- 找名称里带“Virtual”“SVM”“VT”字样的选项。
- 如果整个页面密密麻麻找不到，直接用固件自带的搜索框搜。现在多数 UEFI 界面右上角都有搜索按钮，输入“Virtual”或“SVM”就能直接跳转。
笔记本和品牌台式机的情况稍复杂一点。部分 OEM 厂家为了简化界面，会把虚拟化选项藏在隐藏的高级菜单里，默认根本不显示。当年我也在这上面卡过将近一下午，后来尝试“Load Optimized Defaults”恢复默认配置，虚拟化反而变成了 Enabled。所以如果你在 BIOS 里翻遍所有页面都找不到相关选项，可以先试试恢复默认设置再查一次，比对着说明书硬找效率高得多。
还有一类很隐蔽的情况：有些机器 BIOS 里的虚拟化选项和 Windows 系统侧的安全设置联动，单纯在 BIOS 打开后，系统检测不到变更效果。这种一般更新 BIOS 或按上面说的恢复默认就能解决，不必过度恐慌。
2.3 保存退出后的状态确认
设置完成后，按 F10 保存并退出，大多数固件会问你“Save and Exit？”，确认即可。重进系统前我建议再进一次 BIOS，确认选项状态确实变成了 Enabled。因为经常有人快捷键按错，退出去的时候没保存，或者选成了“Exit Without Saving”，白折腾半天。如果 BIOS 里确认已开启但进系统后任务管理器仍显示“已禁用”，最可能的原因是 CMOS 电池老化或主板固件设置被意外重置，这种情况重新设置一遍一般能恢复。
另外提醒一句，部分主板会为“虚拟机监控程序”提供单独的启动开关，比如某些设备管理界面里叫“Management Engine”或“Intel SGX”，别误关这些，它们和 VT-x 不是一回事。普通用户只需要确保 VT-x/SVM 是 Enabled，其他和虚拟化相关的非必要选项可以先不动。
3. 系统侧关闭 Hyper-V 的三条路径：功能开关、bcdedit 与 PowerShell 的适用场景
3.1 路径一：Windows 可选功能面板，图形化操作最稳妥
如果虚拟化被报告占用，第一件事是打开 Windows 功能面板，把 Hyper-V 相关项去掉。最干净的操作路径是：Win+R 输入 optionalfeatures 回车，或者从控制面板 → 程序 → 启用或关闭 Windows 功能进入。
在弹出窗口里，我建议重点取消勾选下面几个项：
- Hyper-V（整个节点，包括 Hyper-V 管理工具和 Hyper-V 平台）
- Windows 虚拟机监控程序平台（Windows Hypervisor Platform）
- 虚拟机平台（Virtual Machine Platform）
- Windows 沙盒（Windows Sandbox）
其中“虚拟机平台”是 WSL2 依赖的组件，如果你后面还需要 WSL2，可以暂时留着，但如果你当下的诉求就是让 VMware/VirtualBox 能正常用，最好也一并关掉，免得 vmcompute 服务把 Hyper-V 组件反复拉起来。点确定后系统会提示重启，一定要重启，不要想着“先不重启再等等”。
图形化路径比较适合普通用户，因为每一步都可见，不会出现命令行敲错然后一脸懵的情况。一个缺点是 Windows 功能面板改动后，系统可能要花几分钟做组件卸载，重启时间比平时长，这属于正常现象，别中途强制断电。
3.2 路径二：bcdedit 只关闭 Hypervisor 启动，改动最小
有些时候你在功能面板里把 Hyper-V 全部取消勾选，也重启了，但 msinfo32 里依然提示“检测到一个虚拟机监控程序”。这时候第二个手段就该上场了。用管理员身份打开命令提示符或 PowerShell，执行：
bcdedit /set hypervisorlaunchtype off然后重启机器。这个命令的作用很直接：修改 Windows 启动配置，让 Hypervisor 在系统启动时不被加载。即便某些功能在注册表里还留着 Hyper-V 组件的痕迹，只要 hypervisor 没有启动，第三方虚拟机软件就不会再和它抢占 VT-x。
如果想恢复，把 off 改成 auto 再重启即可：
bcdedit /set hypervisorlaunchtype auto这个思路我特别推荐给那些不想动系统功能、只想临时关掉 hypervisor 的人。它的优点是改动最小、见效最快；缺点是它不影响 Windows 功能的勾选状态，以后如果你运行了会重置启动配置的工具，可能又会被改回去。
3.3 路径三：PowerShell 批量控制功能项
如果你更习惯命令行，或者需要在一台机器上批量处理多个功能组件，可以用 PowerShell 来做。先查看当前状态：
Get-WindowsOptionalFeature -Online | Where-Object {$_.FeatureName -match 'Hyper|Virtual|Sandbox'} | Format-Table FeatureName, State这个命令会列出和虚拟化相关的功能项以及它们的启用状态。确认哪些在启用后，再针对性禁用：
Disable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All -NoRestart注意，Microsoft-Hyper-V-All包含的是 Hyper-V 管理工具和平台组件，Hypervisor 平台和虚拟机平台分别是单独的功能名。如果只想禁用某个具体项，可以先从上面的查询结果里拿到完整 FeatureName 再执行禁用，避免误伤。用-NoRestart参数可以暂时不重启，但最终想要生效，重启这步还是省不掉。
3.4 三条路径的取舍与推荐组合
这三条路径不是互斥的，我实际处理时经常组合使用：
- 普通用户优先选功能面板，点掉勾选项重启即可。
- 如果功能面板处理后仍然检测到虚拟机监控程序，再用 bcdedit 把 hypervisor 启动关掉，作为兜底。
- PowerShell 比较适合批量部署或远程操作场景，对应那种要给多台电脑统一做虚拟化配置的情况。
推荐组合是：功能面板取消勾选相关项 + bcdedit 设置 hypervisorlaunchtype off + 重启。这套组合下，大部分用户的 VMware/VirtualBox 就能正常跑起来了。但事情还没完，因为在 Windows 11 上，还有一个特别隐蔽的“房客”可能还在占着虚拟化资源。
4. 关了 Hyper-V 仍被占用：Windows 11 的“隐形住户”内核隔离与 VBS
4.1 现象：功能关闭、bcdedit 也执行了，msinfo32 仍显示检测到虚拟机监控程序
如果你已经按上一章的方法做完，打开 msinfo32 却依然看到“检测到一个虚拟机监控程序”，先别急，这不是你操作错了，而是 Windows 10/11 里另一个安全机制在捣乱。这个机制叫“基于虚拟化的安全性”（VBS），其中最常见的表现就是 Windows 安全中心里的“内核隔离 → 内存完整性”。
内存完整性这项功能本身是安全用的，它通过让 Windows 核心进程跑在虚拟化隔离环境里，来防止恶意软件篡改内核。听起来挺好，但它有一个副作用：为了创建这个隔离环境，Windows 必须启动 hypervisor。也就是说，即使你把 Hyper-V 相关功能全关了，只要内存完整性还开着，hypervisor 照样会在后台启动，照样把 VT-x 占住。
很多刚用 Windows 11 的人就是栽在这里。他们明明记得自己没装过任何虚拟机软件，也没勾过 Hyper-V，但一查 msinfo32 就是“已检测到”，打开第三方模拟器还特别卡。这就是 Windows 11 默认开启 VBS 带来的连锁反应。
4.2 关闭“内存完整性”的具体步骤
关闭内存完整性不复杂，但路径稍微隐蔽。操作如下：
- 打开 Windows 安全中心。
- 左侧选择“设备安全性”。
- 点击“内核隔离”下的“内核隔离详细信息”。
- 关闭“内存完整性”开关。
- 系统会提示需要重启，确认后重启。
重启后再看 msinfo32，如果“虚拟机监控程序”那行变成了“未检测到”，说明一切都干净了。如果你的机器没有显示内核隔离选项，可能是 CPU 或固件不支持 VBS，这种反而省心，不会出现这个隐形占用问题。
需要提醒一句：关闭内存完整性确实会降低一部分系统安全性。个人折腾虚拟机时关掉它问题不大，但如果你在公司统一管理的电脑上，最好先确认安全策略允许，不要随意关，免得合规上出问题。这个取舍自己要清楚。
4.3 注册表层面彻底关闭基于虚拟化的安全性
有些机器就算关了“内存完整性”，重启后 msinfo32 里“基于虚拟化的安全性”仍然显示“正在运行”。这是比较顽固的情况，常见于带有 Credential Guard 或设备保护策略的系统。这时候需要在注册表里把 VBS 开关强制关闭。
用管理员身份打开命令提示符，执行这三条命令：
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v EnableVirtualizationBasedSecurity /t REG_DWORD /d 0 /f reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v Enabled /t REG_DWORD /d 0 /f reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\CredentialGuard" /v Enabled /t REG_DWORD /d 0 /f第一条是把 VBS 的总开关设为 0，第二条针对内存完整性（HVCI），第三条针对凭据保护（Credential Guard）。执行完重启，再进 msinfo32 确认，“基于虚拟化的安全性”通常就会变成“未启用”或“已禁用”。
这里多说一句：如果你这台的 Windows 是专业版或企业版，并且启用了本地组策略，也可以在计算机配置 → 管理模板 → 系统 → Device Guard里把“启用基于虚拟化的安全性”设为“已禁用”。两条路取其一即可。注册表方式在家庭版上也能用，普适性更强。
5. 实测验证、翻车现场与按需取舍：虚拟化最终配置方案
5.1 三种验证方式：任务管理器、msinfo32 和 Coreinfo
所有操作做完后，验证环节很关键。我常用的验证方法有三个：
- 任务管理器 → 性能 → CPU：右下角“虚拟化”显示“已启用”。这证明硬件层面 VT-x/SVM 已经可用。
- 系统信息 msinfo32：在系统摘要最下方看“虚拟机监控程序”一栏，只要显示“未检测到”，就说明没有 hypervisor 抢占，第三方虚拟机软件可以正常使用硬件虚拟化。
- Coreinfo 确认：下载 Sysinternals 的 Coreinfo，管理员模式运行
coreinfo -v，VT-x 那行看到 * 而不是 -，才是最彻底的确认。
如果你打开 VirtualBox 或 VMware 后不再弹硬件虚拟化错误，说明前面所有步骤都生效了。如果还不行，大概率是前面哪一步没做彻底，或者有第三方软件把虚拟化占用了。看下一节的排查顺序。
5.2 设置都做了但依然失败的排查顺序
我按实际遇到的频率整理了一个问题排查顺序，按表格来看更清晰：
| 现象 | 最可能原因 | 处理方式 |
|---|---|---|
| BIOS 选项已启用，任务管理器仍显示“已禁用” | BIOS 未真正保存或固件重置 | 重进 BIOS 确认选项，必要时 Load Optimized Defaults 再设置 |
| CPU 虚拟化任务管理器显示已启用，虚拟机软件仍报错 | hypervisor 正运行 | 用 msinfo32 看“虚拟机监控程序”，确认后走第三、四章完整流程 |
| bcdedit 已设置 off，重启后自动恢复 | 系统更新或第三方工具重置启动配置 | 重新执行 bcdedit 命令，排查是否有优化软件在改启动项 |
| 关闭 Hyper-V 后系统开机特别慢 | 组件卸载未完成而已 | 多等几分钟，确认更新完成后重启一次 |
| 关闭后虚拟机启动直接蓝屏 | 虚拟机软件驱动残留 | 彻底卸载旧版虚拟机软件，用官方清理工具清驱动后再装新版 |
| 游戏或模拟器提示虚拟化被占用 | VBS 或 hypervisor 仍在运行 | 按第四章思路关闭内核隔离和 VBS 注册表项 |
这个排查顺序本质上是“先硬件，再系统功能，再安全机制，再第三方驱动”的自底向上思路。大多数人的问题出在第三步以后——BIOS 明明开得好好的，却被安全机制偷偷拦截。
5.3 需要 WSL2 或 Docker 时的取舍与替代方案
事情到这里，还得泼一盆冷水：如果你关掉 Hyper-V 和 VBS，意味着依赖这些底层的功能也会受影响。最典型的就是 WSL2 和 Docker Desktop。
WSL2 的运行依赖“虚拟机平台”和 hypervisor 启动。你把 virtual machine platform 和 hypervisorlaunchtype 都关了，WSL2 将无法启动或者退化到 WSL1。Docker Desktop 目前主流用的是 WSL2 后端，一样会受影响。也就是说，你是“要本地虚拟机”还是“要 WSL2/Docker”，这俩在某些场景下确实得有所取舍。
我的做法比较务实：如果当天主要跑 VMware 或安卓模拟器，就把 hypervisor 关掉，换来最佳性能和兼容性；如果后面要跑 Docker 了，再用一条命令把 hypervisor 打开，重启切过去。两边虽然都要重启机器，但实际上就一分多钟的事情，换来的是两条路线都不委屈自己。下面这两个脚本建议保存为管理员运行的批处理文件：
bcdedit /set hypervisorlaunchtype off shutdown /r /t 0bcdedit /set hypervisorlaunchtype auto shutdown /r /t 0日常开发如果确实离不开 WSL2，那就不要强行把 hypervisor 关死。新版本的 VMware Workstation 已经支持在 Windows Hypervisor Platform 上运行，虽然性能有折扣，但至少能共存。VirtualBox 近几个版本也支持与 Windows Hypervisor 共存，普通用途完全够用。
5.4 最终推荐配置表
根据你的实际用途，我最后整理一张可以照着抄的配置表：
| 使用场景 | 推荐配置 |
|---|---|
| 只跑虚拟机/安卓模拟器/游戏 | 取消 Hyper-V、虚拟机平台、Windows Hypervisor Platform、沙盒勾选；bcdedit off；关闭内核隔离和 VBS；重启 |
| 日常开发依赖 WSL2/Docker | 保留“虚拟机平台”；hypervisor 保持 auto；使用支持 WHPX 的新版虚拟机软件；接受性能折扣 |
| 两边都要且追求干净 | 准备上面两个切换脚本，按需重启切换，避免长期共存带来的隐性性能损失 |
| 公司/实验室统一安全策略 | 先咨询管理员，不要私自关闭 VBS 相关防护，可优先尝试 Hyper-V 官方虚拟机方案 |
说实话，Windows 的虚拟化配置本身并不复杂，难的是很多人不知道“开启 CPU 虚拟化”和“关闭 Hyper-V”是两件事，更不知道 Windows 11 还有一个和安全绑定的 VBS 会静默启动 hypervisor。把这些隐藏的占位找出来，一次性全部关掉，再验证到 msinfo32 显示“未检测到虚拟机监控程序”，你就能彻底告别那种“明明 BIOS 开了但还是不行”的诡异体验。按照上面的顺序逐步排查，绝大多数情况都能一次性解决。
