VMware与Hyper-V冲突全解析：从报错原理到关闭VBS及兼容模式配置

1. 这个报错到底在说什么：从Hyper-V与Device/Credential Guard的底层冲突讲起

装VMware Workstation的时候弹出一行字：“安装程序检测到主机启用了Hyper-V或Device/Credential Guard……”，然后安装直接卡死或者回滚。这个场景我遇到过太多次了，身边做开发、做测试、搞运维的朋友几乎人手一份。很多人第一反应是“我明明没开过Hyper-V啊”，但问题恰恰出在这里——你没主动开，不代表它没开。

先把结论摆在前面：这不是VMware的bug，也不是你系统坏了，而是Windows的虚拟化底层被另一套机制占用了。VMware Workstation要跑虚拟机，需要拿到CPU的VT-x/AMD-V硬件虚拟化指令的控制权，也就是常说的“Ring -1”层。而Hyper-V一旦启用，Windows的Hypervisor会先一步接管这个层级，把自己变成最底层的虚拟化层。这时候VMware再想直接调用硬件虚拟化，就变成了“在虚拟机里再跑虚拟机”，也就是嵌套虚拟化。VMware Workstation对嵌套虚拟化的支持一直很有限，所以安装程序检测到Hyper-V存在时，会直接拒绝继续。

这里有个关键点很多人搞混：Hyper-V不等于“Hyper-V管理器”这个功能。哪怕你在“启用或关闭Windows功能”里没勾选Hyper-V，下面这些机制同样会触发Hypervisor启动：

• Device Guard（设备防护）和Credential Guard（凭据防护）：这是基于虚拟化的安全（VBS）功能，Windows 10/11专业版和企业版默认可能开启，尤其是加入了域或者用了Windows Hello的企业环境。
• Windows沙盒（Windows Sandbox）：它底层依赖Hyper-V。
• WSL2：Windows Subsystem for Linux 2 用的是轻量级Hyper-V架构。
• Windows Defender Application Guard：同样基于Hyper-V隔离。
• 内存完整性（Core Isolation / Memory Integrity）：在Windows安全中心里，这个开关一开，VBS就起来了。
• 虚拟化安全（VBS）本身：Windows 11默认对全新安装的设备启用。

所以你会看到一个很反直觉的现象：一台看起来“干干净净”的Windows 11，什么都没装，VMware却报Hyper-V冲突。原因就是Windows 11默认开启了基于虚拟化的安全功能，Hypervisor在后台悄悄跑着。

我自己的判断逻辑是这样的：先别急着关这关那，先确认到底是谁占用了虚拟化层。打开系统信息（msinfo32），看最下面一行“基于虚拟化的安全性”，如果是“正在运行”，那基本就实锤了。再看“Hyper-V - 要求”那一块，如果显示“是”，说明Hypervisor已经启动。这个信息比在功能列表里翻来翻去靠谱得多，因为功能列表只能看到你手动勾选的东西，看不到VBS这种“隐形”开启的机制。

理解了这一层，后面的所有操作才有方向：要么让Hyper-V/VBS让路，要么让VMware学会和Hyper-V共存。两条路各有代价，选哪条取决于你的实际使用场景。下面我会把两条路都拆开讲清楚，包括每一步为什么这么做、做完怎么验证、以及我踩过的那些坑。

2. 先判断该走哪条路：关掉安全功能还是让两者共存

在动手之前，必须先做一个决策。这个决策做错了，后面全是白费功夫。核心判断依据只有一个：你当前和未来一段时间，是否必须使用依赖Hyper-V的功能。

2.1 什么情况下应该关掉Hyper-V和VBS

如果你符合下面这些情况，关掉是更省事的选择：

• 你只是想在VMware Workstation里跑Linux、跑Windows测试机、做实验，不需要WSL2、不需要Windows沙盒、不需要Docker Desktop的WSL2后端。
• 你用的是个人电脑，不涉及企业域的凭据防护策略。
• 你对“内存完整性”这类安全功能没有硬性要求，或者能接受临时关闭。
• 你追求VMware Workstation的完整性能和兼容性，尤其是需要嵌套虚拟化、需要跑macOS虚拟机、需要USB设备直通等场景。

关掉之后，VMware Workstation能直接拿到硬件虚拟化控制权，性能最好，兼容性最广，报错彻底消失。代价是WSL2、Windows沙盒、Docker Desktop（WSL2模式）这些会用不了，或者需要切换后端。

2.2 什么情况下应该保留Hyper-V并让VMware共存

如果你符合这些情况，就别关：

• 你在用WSL2做日常开发，或者用Docker Desktop且后端是WSL2。
• 你在用Windows沙盒做隔离测试。
• 公司电脑有Device Guard/Credential Guard策略，你根本没有权限关。
• 你需要同时跑Hyper-V虚拟机和VMware虚拟机。

这种情况下，正确的做法是升级到VMware Workstation Pro 15.5.5及以上版本，或者VMware Workstation 16/17。从15.5.5开始，VMware引入了对Hyper-V的兼容模式，底层通过Windows Hypervisor Platform（WHP）API来运行，不再直接抢占硬件虚拟化层。也就是说，VMware把自己变成了Hyper-V上面的一个“客人”，和WSL2、沙盒平起平坐。

但这里有个必须说清楚的代价：兼容模式下的性能会下降。根据我的实测，磁盘IO和网络吞吐大概会损失10%到30%，具体取决于负载类型。CPU密集型任务影响小一些，IO密集型任务影响明显。另外，嵌套虚拟化在兼容模式下基本不可用，也就是说你没法在VMware的虚拟机里再跑虚拟机。如果你要跑Android模拟器、要测试Hyper-V嵌套，那兼容模式会让你很痛苦。

我个人的选择逻辑是：主力开发机如果重度依赖WSL2，就保留Hyper-V，用VMware 17的兼容模式，接受性能损失；如果是专门的测试机或者需要跑嵌套虚拟化，就关掉Hyper-V和VBS，让VMware独占。这个取舍没有标准答案，取决于你每天到底在干什么。

还有一个折中方案：双系统或者双引导。在同一个物理机上装两个Windows，一个开Hyper-V给WSL2用，一个关掉给VMware用。听起来麻烦，但对于需要同时兼顾两种场景的人来说，这是最干净的方案。我自己有一台测试机就是这么干的，切换成本就是重启一次，但两边都能拿到最佳性能。

3. 彻底关闭Hyper-V与VBS的完整操作链路

决定要关之后，操作不能只关一个地方。很多人只关了“启用或关闭Windows功能”里的Hyper-V，结果重启后VMware还是报错，就是因为VBS、内存完整性、Credential Guard这些没关干净。下面是我总结的完整链路，按顺序执行，每一步都别跳过。

3.1 第一步：关闭Windows功能中的Hyper-V相关项

打开“控制面板” -> “程序和功能” -> “启用或关闭Windows功能”，找到下面这些项，全部取消勾选：

• Hyper-V（包括管理工具和平台）
• Windows Hypervisor Platform（这个特别容易被忽略，它是WHP API，VMware兼容模式依赖它，但如果你要彻底关Hyper-V，这个也要关）
• 虚拟机平台（Virtual Machine Platform，WSL2依赖它）
• Windows沙盒（Windows Sandbox）
• Windows Defender Application Guard（如果有）
• 容器（Containers，如果不需要）

取消勾选后，系统会提示重启。先别急着重启，继续做后面的步骤，全部做完再一次性重启，省时间。

注意：有些Windows 11版本里，“虚拟机平台”和“Windows Hypervisor Platform”是分开的，两个都要关。只关Hyper-V本身不够。

3.2 第二步：关闭内存完整性和VBS

打开“Windows安全中心” -> “设备安全性” -> “内核隔离” -> “内存完整性”，把开关拨到关闭。这个操作会触发一次重启提示，同样先别重启。

如果“内存完整性”开关是灰色的，说明你的设备可能被策略锁定了，或者CPU不支持。这种情况下需要往下走组策略和注册表的路子。

3.3 第三步：用bcdedit关闭Hypervisor启动

以管理员身份打开命令提示符（CMD）或PowerShell，执行：

bcdedit /set hypervisorlaunchtype off

这条命令的作用是告诉Windows引导管理器，不要在启动时加载Hypervisor。执行成功会显示“操作成功完成”。这是最关键的一步，很多人前面都关了，但Hypervisor还是被引导加载了，就是因为这个设置没改。

执行完之后，可以再用bcdedit /enum确认一下，看“hypervisorlaunchtype”这一项是不是“Off”。

3.4 第四步：处理Device Guard和Credential Guard的组策略

这一步主要针对专业版、企业版、教育版。家庭版可以跳过，但家庭版通常也没有Credential Guard。

打开“本地组策略编辑器”（gpedit.msc），依次展开：

• 计算机配置 -> 管理模板 -> 系统 -> Device Guard

找到“打开基于虚拟化的安全”，把它设置为已禁用。

然后展开：

• 计算机配置 -> 管理模板 -> 系统 -> Credential Guard

找到“打开基于虚拟化的安全以隔离凭据”，同样设置为已禁用。

如果这两个策略项在你的系统里不存在，说明你的Windows版本不支持或者已经被移除了，不影响。

3.5 第五步：注册表层面的VBS禁用（兜底）

有些情况下组策略不生效，或者家庭版没有组策略，就需要直接改注册表。以管理员身份运行regedit，定位到：

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard

把EnableVirtualizationBasedSecurity的值改为0。如果没有这个项，可以手动新建一个DWORD（32位）值。

再定位到：

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

把LsaCfgFlags的值改为0。这个值控制Credential Guard，设为0表示禁用。

提示：改注册表之前建议先导出备份，万一改错了可以恢复。虽然这几项改错了一般也不会导致系统起不来，但养成备份习惯没坏处。

3.6 第六步：重启并验证

前面五步全部做完，重启电脑。重启后，用下面几个方法验证是否关干净了：

1. 打开系统信息（msinfo32），看“基于虚拟化的安全性”是否变成“未启用”。如果还是“正在运行”，说明没关干净。
2. 打开任务管理器-> “性能” -> “CPU”，看右下角“虚拟化”是否显示“已启用”。注意这个显示的是CPU硬件虚拟化是否开启，和Hyper-V是否运行是两回事。硬件虚拟化应该保持“已启用”，否则VMware也用不了。
3. 再次运行VMware安装程序，看报错是否消失。

如果msinfo32里VBS还是“正在运行”，大概率是Device Guard的组策略没生效，或者有域策略在强制推送。这种情况下，如果是公司电脑，建议直接找IT；如果是个人电脑，检查组策略和注册表是否都改到位了。

3.7 我踩过的两个坑

第一个坑：只关了Hyper-V功能，没关“虚拟机平台”。结果WSL2虽然用不了，但Hypervisor还是被加载了，VMware照样报错。后来才发现“虚拟机平台”这个功能独立于Hyper-V，必须单独关。

第二个坑：bcdedit命令执行了，但没重启就测试。bcdedit改的是引导配置，必须重启才生效。我当时急着验证，没重启就运行VMware，当然还是报错，白白折腾了半小时。

4. 保留Hyper-V的共存方案：VMware Workstation的兼容模式怎么配

如果你决定保留Hyper-V，那核心思路就是让VMware走Windows Hypervisor Platform（WHP）API。这条路从VMware Workstation 15.5.5开始支持，16和17版本体验更好。下面说清楚怎么配、怎么验证、以及性能上到底损失多少。

4.1 版本选择和安装要点

首先确认你的VMware Workstation版本。打开VMware，点“帮助” -> “关于”，看版本号。必须15.5.5及以上，低于这个版本不支持WHP兼容模式。建议直接用16.2或17.x，稳定性和性能都更好。

安装的时候有个细节：如果你之前装过旧版本，建议先彻底卸载，包括清理注册表和残留驱动。VMware的卸载有时候不干净，旧驱动残留会导致新版本安装后行为异常。我一般会用官方卸载工具或者手动清理C:\Program Files (x86)\VMware和注册表里的VMware项。

安装过程中，如果检测到Hyper-V，新版本会提示你“将使用Windows Hypervisor Platform”，这是正常的，继续装就行。装完之后不需要额外配置，VMware会自动检测并走WHP。

4.2 验证是否走了兼容模式

装完之后，打开VMware，创建一个虚拟机或者打开已有的虚拟机，看虚拟机设置里“处理器”那一项。如果“虚拟化引擎”下面的“虚拟化Intel VT-x/EPT或AMD-V/RVI”选项是灰色的，或者提示“此平台不支持”，说明当前走的是WHP兼容模式，嵌套虚拟化不可用。

另一个验证方法是看虚拟机启动时的日志。VMware的日志文件在虚拟机目录下，文件名是vmware.log。搜索“Hyper-V”或者“WHP”，如果看到类似“Using Windows Hypervisor Platform”的字样，说明兼容模式生效了。

4.3 兼容模式下的性能实测数据

我在一台i7-12700H、32GB内存、NVMe SSD的笔记本上做过对比测试，宿主是Windows 11 22H2，VMware Workstation 17 Pro，虚拟机是Ubuntu 22.04，分配4核8GB。

从数据能看出来，CPU和内存影响很小，磁盘和网络影响明显。所以如果你的虚拟机主要跑计算任务，兼容模式完全能接受；如果跑数据库、跑文件服务、跑网络密集型应用，那25%左右的IO损失就比较肉疼了。

还有一个隐性成本：兼容模式下虚拟机的启动时间会变长。我实测Ubuntu 22.04冷启动，独占模式大概8秒，兼容模式大概12秒。原因是WHP的初始化流程比直接调用硬件虚拟化多了一层。

4.4 兼容模式下哪些功能会受限

除了嵌套虚拟化不可用，还有几个功能会受影响：

• USB设备直通：部分USB 3.0设备在兼容模式下可能无法直通，或者需要额外配置。
• 3D加速：VMware的3D加速在WHP模式下性能下降明显，跑图形界面会感觉卡顿。
• 虚拟机暂停/恢复：兼容模式下暂停恢复的可靠性不如独占模式，偶尔会出现恢复后网络不通的情况。
• macOS虚拟机：基本别想了，兼容模式下跑macOS虚拟机几乎不可用。

所以如果你需要这些功能，还是老老实实关Hyper-V走独占模式。

5. 那些容易被忽略的关联问题：WSL2、Docker Desktop和嵌套虚拟化

关Hyper-V这件事，牵一发动全身。很多人关完之后发现WSL2起不来了、Docker Desktop报错了、Android模拟器变慢了，然后又慌慌张张去开回来。这一章把这些关联问题一次性讲清楚。

5.1 WSL2无法启动的连锁反应

WSL2依赖“虚拟机平台”和Hypervisor。你把Hyper-V和虚拟机平台关了，WSL2自然就起不来，报错通常是“此计算机上未启用虚拟化”或者“WSL2无法启动，因为此计算机上未启用虚拟机平台”。

这时候你有两个选择：

• 降级到WSL1：执行wsl --set-version <发行版名> 1，把WSL2切回WSL1。WSL1不依赖Hyper-V，但兼容性和性能差很多，尤其是文件系统操作。
• 接受WSL2不可用：如果你只是偶尔用WSL，可以临时用虚拟机里的Linux替代。

我个人的做法是：如果这台机器以VMware为主，就不装WSL2，需要Linux环境直接在VMware里跑。如果以WSL2为主，就用VMware的WHP兼容模式。两边都想要最佳体验，那就双系统。

5.2 Docker Desktop的后端切换

Docker Desktop在Windows上有两种后端：WSL2后端和Hyper-V后端。如果你关了Hyper-V，Docker Desktop会提示你切换到WSL2后端，但WSL2又依赖虚拟机平台，所以实际上两个后端都用不了。

解决办法只有两个：要么开回Hyper-V用Docker，要么在VMware的Linux虚拟机里装Docker。后者其实更干净，Docker跑在Linux里本来就是原生体验，性能也比Windows上的Docker Desktop好。我现在主力开发就是在一台Ubuntu虚拟机里跑Docker，宿主Windows只负责VMware，互不干扰。

5.3 嵌套虚拟化的实际需求判断

“嵌套虚拟化”这个词听起来很高级，但很多人其实并不需要。你需要嵌套虚拟化的典型场景是：

• 在VMware的Windows虚拟机里再跑Hyper-V或WSL2。
• 在VMware的Linux虚拟机里跑KVM。
• 用Android Studio的模拟器，且模拟器需要硬件加速。
• 测试虚拟化相关的软件，比如Proxmox、ESXi的嵌套实验。

如果你没有这些需求，嵌套虚拟化对你来说就是个可有可无的功能，不用为了它纠结。反过来，如果你确实需要，那就只能关Hyper-V走独占模式，没有别的选择。

5.4 一个容易被忽略的点：Windows Hello和Credential Guard的关系

有些企业环境里，Credential Guard是和Windows Hello for Business绑定的。你关了Credential Guard，可能导致Windows Hello的面部识别或指纹登录失效。这个在热词里也有人提到“关闭windowshello再尝试运行安装程序面部用不了”，说的就是这个情况。

如果你遇到这种问题，正确的顺序是：先确认Credential Guard是否真的需要关，如果只是为了让VMware安装，可以试试升级VMware到17用兼容模式，这样就不用动Credential Guard，Windows Hello也不受影响。如果必须关，那关完之后Windows Hello可能需要重新配置，或者改用PIN登录。

6. 安装完成后的验证与长期维护建议

报错消失、安装完成，不代表事情就结束了。我见过太多人装完之后过几天又出问题，原因是Windows更新或者某个软件又把Hyper-V相关功能打开了。这一章说说装完之后怎么验证、怎么防止反弹。

6.1 安装后的三项验证

装完VMware Workstation后，别急着庆祝，先做三个验证：

1. 创建一台测试虚拟机并启动：分配2核4GB，装个Ubuntu或者随便什么系统，确认能正常启动、能正常关机、网络能通。这一步是验证VMware是否真的拿到了虚拟化控制权。
2. 检查虚拟机设置里的虚拟化选项：打开虚拟机设置 -> 处理器，看“虚拟化Intel VT-x/EPT或AMD-V/RVI”是否能勾选。如果能勾选，说明独占模式生效；如果灰色，说明还在兼容模式或者Hyper-V没关干净。
3. 跑一个简单的性能测试：在虚拟机里执行dd if=/dev/zero of=testfile bs=1M count=1024，看写入速度。如果速度明显低于宿主SSD的正常水平（比如低于500MB/s），说明可能还在兼容模式。

6.2 防止Windows更新重新开启VBS

Windows 11的大版本更新（比如22H2升23H2）有时候会重置VBS设置，把内存完整性重新打开。我遇到过两次，更新完重启后VMware又报错了。

预防措施：

• 更新完Windows后，第一时间检查msinfo32里的VBS状态。
• 如果被重置了，重新执行bcdedit命令和组策略设置。
• 可以考虑写一个批处理脚本，每次开机自动检查并关闭VBS相关设置。不过这个做法有点激进，可能影响系统安全更新，我不太推荐普通用户这么干。

6.3 长期使用中的性能监控

如果你走的是WHP兼容模式，建议定期关注虚拟机的性能表现。VMware自带的性能监控可以看CPU、内存、磁盘、网络的实时数据。如果发现磁盘IO异常低，可能是WHP的驱动出了问题，重装VMware Tools或者更新VMware版本通常能解决。

另外，VMware Workstation 17对WHP的优化比16好不少，如果你还在用16，建议升级到17。我在同一台机器上对比过，17的磁盘IO比16提升了大概15%，网络吞吐提升了10%左右。

6.4 我的个人经验总结

折腾VMware和Hyper-V冲突这件事，我从Workstation 12时代就开始遇到，到现在Workstation 17，前前后后装了不下几十次。最大的体会是：先搞清楚自己的使用场景，再决定技术方案，不要盲目跟着网上的教程关这关那。

如果你只是偶尔用虚拟机，关掉Hyper-V和VBS是最省事的，十分钟搞定，性能最好。如果你每天都用WSL2或者Docker，那就别关，升级VMware用兼容模式，接受那20%左右的IO损失。如果你两边都重度使用，双系统或者两台机器是最靠谱的方案。

还有一个细节：VMware Workstation Pro从17开始对个人用户免费了，下载和安装都比以前方便。如果你还在用旧版本，建议直接上17，很多兼容性问题在新版本里已经优化过了。

最后说一个我最近发现的技巧：如果你不想关VBS但又需要跑嵌套虚拟化，可以试试在VMware虚拟机里用QEMU/KVM而不是Hyper-V。QEMU在WHP兼容模式下对嵌套虚拟化的支持比Hyper-V好一些，虽然性能还是有损失，但至少能跑起来。这个方案比较小众，适合喜欢折腾的人。