Win11 虚拟机 VT-x/EPT 报错：分层排查与修复实战

Win11 上跑 VM，启动虚拟机那一刻弹出一句“此平台不支持虚拟化的 Intel VT-x/EPT”，这大概是近两年桌面虚拟化里最容易被误判的一条报错。它不像蓝屏那样给出明确错误码，也不像缺文件那样指向具体路径，而是把“CPU 硬件能力”“固件开关”“操作系统占用”“软件版本”四件事混在一句话里，让人第一反应往往是“我 BIOS 里明明开了 VT-x”。实际情况是，Win11 默认启用的基于虚拟化的安全性、内存完整性、虚拟机平台，以及 WSL2、沙盒这类功能，都会在系统启动时抢先占据处理器的虚拟化根模式，VM 软件再去申请时就会扑空；再加上新机器出厂固件默认关闭虚拟化、部分品牌机 BIOS 选项被精简，这个报错在 Win11 上的出现频率远高于 Win10 时代。这篇内容面向刚接触桌面虚拟化的新手，也面向被这个问题反复折磨的老用户，我会按“先看懂报错、再分层排查、最后动手修”的顺序，把每一步的判断依据、操作细节和踩坑经验都摊开讲，读完你能自己定位问题出在哪一层，而不是照着网上零散的教程一个个试。

1. 报错原文到底在说什么

1.1 VT-x 与 EPT 是两颗不同的硬件开关

很多人把这条报错理解成“VT-x 没开”，其实它同时点了两个技术名词。VT-x 是处理器提供的硬件辅助虚拟化指令集，它让虚拟机监视器可以运行在一个比操作系统内核更低的特权层级上，直接接管部分硬件资源，而不需要靠二进制翻译去模拟每一条指令。没有 VT-x，VM 软件只能走纯软件模拟，速度慢到几乎不可用。EPT 则是另一套东西，全称是扩展页表，解决的是虚拟机内存地址翻译的开销问题。传统方案里，虚拟机访问一次内存，要经过“虚拟地址到虚拟机物理地址”和“虚拟机物理地址到宿主机物理地址”两次转换，软件维护的影子页表会带来大量额外开销；EPT 让处理器硬件直接完成第二层转换，把这两步压缩成一次查表。用个通俗的类比：VT-x 相当于给虚拟机单独隔出了一间办公室，让它有自己的门牌和权限；EPT 相当于给这间办公室配了一本直通的地址簿，快递员不用每次都去前台手工换算楼层。两件事缺一件，虚拟机要么根本起不来，要么起来之后卡得没法用。报错把两者并列写出来，是因为 VM 软件在初始化阶段会同时申请 VMX 根模式操作权限和 EPT 能力，任何一项拿不到，就会抛出这句统一的提示。

这里还有一个容易被忽略的点：不同厂商对这两项能力的叫法不一样。同类的二级地址转换技术在别的平台上叫法不同，但原理一致。所以你如果在固件里翻遍菜单也找不到“EPT”三个字，不要慌，EPT 通常不需要单独开关，它随 VT-x 一起被启用，固件里能看到的往往只有“虚拟化技术”“VT-d”“IOMMU”这几项。真正需要你手动打开的，是 VT-x 这一层；EPT 是否可用，要看处理器型号和固件是否完整暴露了这项能力。少数老处理器只支持 VT-x 不支持 EPT，这种机器跑现代虚拟机软件就会一直报错，属于硬件天花板，软件层面怎么调都没用。

1.2 为什么 Win11 上这个问题格外集中

Win11 和 Win10 在虚拟化这件事上最大的差别，是微软把“基于虚拟化的安全性”推到了默认开启的位置。内存完整性、凭据保护、虚拟机监控程序保护的代码完整性，这些安全特性底层都依赖同一个 Windows 自带的虚拟机监控程序。系统一启动，这个监控程序就先占了处理器的虚拟化根模式，VM 软件再想拿，只能排队或者降级。更麻烦的是，Win11 还默认鼓励用户开启 WSL2、Windows 沙盒、容器这些功能，它们同样依赖“虚拟机平台”这个系统组件。一个普通开发者的机器上，很可能同时开着内存完整性、WSL2 和 Docker Desktop，这三样东西叠加起来，虚拟化资源早就被瓜分干净了。

第二个原因是固件层面的。新出厂的笔记本和品牌台式机，BIOS 里虚拟化选项默认是关闭的，厂商出于安全和稳定考虑不愿意默认打开；部分轻薄本的 BIOS 还把高级菜单藏了起来，只留一个笼统的“虚拟化”开关，甚至连这个开关都不给。用户第一次装 VM 软件，装完一启动就报错，回头去 BIOS 里找，发现菜单名称和网上教程对不上，折腾半天也找不到入口。第三个原因是软件版本。VM 软件对 Win11 的适配是分版本推进的，早期版本在 Win11 上会遇到 Hyper-V 共存、大小核调度、驱动签名等一连串问题，表现之一就是这条 VT-x/EPT 报错。三个因素叠在一起，就形成了“明明是同一个报错，原因却可能完全不同”的局面。

1.3 三类典型场景，对应三条不同的排查路线

我把实际遇到的情况归成三类。第一类是全新环境：刚装完 Win11，第一次装 VM 软件，虚拟机一开机就报错。这类问题大概率出在固件开关没开，或者系统默认的安全功能把虚拟化占了，排查顺序应该是先固件、再系统功能、最后看软件版本。第二类是“昨天还能用”：系统打了一次更新、装了一个新软件、或者手贱点开了某个安全设置，之后虚拟机就起不来了。这类问题重点查系统功能的变化，尤其是内存完整性和虚拟机平台有没有被重新打开，Windows 更新有时会把用户手动关闭的安全功能重新启用。第三类是“装了别的东西之后”：装 WSL2、装 Docker、装安卓子系统、装沙盒，这些操作会顺带把 Hyper-V 相关组件拉起来，虚拟机随之报错。这类问题要做的不是修虚拟机，而是做取舍：要么让 VM 软件走兼容模式，接受性能下降；要么关掉那些依赖虚拟化的功能。

还有一类特殊情况值得单独提：公司或学校统一管理的电脑。这类机器上，虚拟化开关可能在固件里被策略锁定，系统功能也可能被组策略强制开启，你本地怎么改都会被覆盖回去。遇到这种情况，先确认自己有没有管理权限，不要盲目跟着教程删功能，改坏了影响正常工作。我在实际处理这类机器时，习惯先跑一遍状态检查，把“固件是否开启、系统是否占用、软件版本多少”三个信息记下来，再决定往哪个方向动手，而不是一上来就改配置。

2. 分层排查：从固件到软件的四步定位法

2.1 第一层：固件里的虚拟化开关真的打开了吗

所有排查的第一步，都应该是确认处理器虚拟化在固件层面是开启的，而不是凭记忆假设。Win11 下有两个很快的检查方法。一个是任务管理器：打开任务管理器，切到“性能”标签，点左侧的 CPU，右下角会有一行“虚拟化”，显示“已启用”或“已禁用”。另一个是系统信息：按 Win+R 输入 msinfo32，在“系统摘要”里找“基于虚拟化的安全性”，能看到“正在运行”或“未启用”。任务管理器那一行反映的是固件是否把虚拟化能力交给了操作系统，如果显示“已禁用”，后面的排查都不用做，直接进固件。

进固件的方法因机器而异，常见的是开机连按 Del、F2、F10、Esc，笔记本上 F2 居多，台式机主板多为 Del。进入后要找的选项名称五花八门：Intel 平台常见“Intel Virtualization Technology”“VT-x”“Virtualization”“Intel VMX”，AMD 平台则是“SVM Mode”“Secure Virtual Machine”。这些选项通常藏在 Advanced、CPU Configuration、Security 这几个菜单下。找到后设为 Enabled，按 F10 保存重启。有的主板还会附带“VT-d”或“IOMMU”选项，它管的是设备直通，跟 VT-x 不是一回事，但如果你以后要用虚拟机直通网卡、硬盘，建议一并打开。

这里有几个实操中的坑。第一，部分品牌机的 BIOS 是精简版，压根没有虚拟化选项，这种情况只能升级 BIOS 或者换机器，没有软件层面的解法。第二，有些机器在电池供电时会限制虚拟化，插上电源再进系统检查一次。第三，改了固件设置重启后，如果系统开了“快速启动”，有可能出现设置没生效的错觉，建议在电源选项里临时关掉快速启动再验证。第四，固件里的设置可能被主板电池老化导致的掉电重置，如果你发现每次断电后虚拟化又变回禁用，换一颗主板电池比反复设置更省事。

2.2 第二层：Windows 自己是不是把虚拟化抢走了

固件确认开启之后，下一个要查的就是系统层面。Win11 里跟虚拟化相关的功能有一长串：Hyper-V、虚拟机平台、Windows 沙盒、WSL、容器、HypervisorPlatform，以及安全侧的内存完整性、凭据保护。它们的关系是：只要其中任何一个在运行，Windows 自带的虚拟机监控程序就会被加载，处理器的虚拟化根模式被它占住，第三方 VM 软件就只能退到兼容模式或者直接报错。

判断系统有没有占用，最直接的方法是看 msinfo32 里的“基于虚拟化的安全性”。如果显示“正在运行”，说明系统级监控程序已经起来了。再看“设备安全性”里的“内核隔离”，内存完整性如果开着，基本可以确定是它占用了虚拟化。还有一个命令行的判断方式：以管理员身份打开终端，执行bcdedit /enum {current}，看输出里有没有hypervisorlaunchtype这一项，值是 Auto 就代表系统启动时会加载虚拟机监控程序，Off 则是不加载。这个值是很多教程里让人改来改去的地方，改完必须重启才生效。

需要说明的是，关闭这些功能是有代价的。内存完整性关掉，系统对恶意驱动的防护会弱一层；Hyper-V 关掉，WSL2、Docker Desktop、Windows 沙盒、安卓子系统这些依赖它的东西会一起罢工。所以正确的做法不是“看到就关”，而是先想清楚这台机器主要用来干什么。如果这台机器是专门的开发测试机，关掉换取虚拟机性能是合理取舍；如果是日常主力机，建议优先考虑让 VM 软件走兼容模式，或者把虚拟机挪到另一台机器上。

2.3 第三层：VM 软件版本和配置文件对不对

固件开了、系统也让出来了，还是报错，就要看软件本身。第一个要确认的是版本。VM 软件对 Win11 的支持是分阶段的，太老的版本不认识新处理器的大小核拓扑，也不支持与系统自带监控程序共存，表现就是各种虚拟化相关报错。判断方法很简单：打开软件的“关于”页面看版本号，再去官方文档核对它支持的最高 Windows 版本。如果版本明显落后，升级往往比调参数更有效。

第二个要确认的是安装时有没有装错组件。有些版本在安装过程中会询问是否安装“与 Hyper-V 兼容的组件”，或者安装包里附带额外的平台支持模块。如果当初一路下一步装完，可能缺了这部分。重新运行安装程序，选择“修改”或“修复”，把相关组件补齐，再重启。

第三个是虚拟机的配置文件。每台虚拟机目录下都有一个以 .vmx 结尾的文本文件，里面记录了这台虚拟机的硬件参数。某些参数会直接影响虚拟化能力的申请，比如控制嵌套虚拟化的开关、控制是否向虚拟机暴露监控程序存在的开关。这些参数在软件图形界面里不一定有对应选项，需要手动编辑。编辑前必须完全退出 VM 软件，先复制一份原文件做备份，用纯文本编辑器打开，改完保存，再启动虚拟机。改错一个字符，虚拟机可能直接打不开，所以这一步要格外小心。

2.4 第四层：硬件能力、驱动和第三方软件

最后一层是硬件和外围因素。处理器的虚拟化能力不是“有或无”这么简单，还要看它支不支持 EPT、支不支持非特权模式下的虚拟化扩展。查看方法可以借助一些系统信息工具，看它输出的 CPU 特性列表里有没有对应的能力项。如果处理器本身不支持 EPT，那这条报错就是硬性限制，换软件版本也没用。

第三方安全软件也值得怀疑。某些带驱动级防护的安全软件会挂钩处理器的虚拟化相关指令，或者在系统启动早期加载自己的监控模块，导致 VM 软件申请资源失败。排查方法是临时退出这类软件再试一次，如果问题消失，就去软件设置里把与虚拟化相关的防护项关掉，或者把 VM 软件加入白名单。

驱动和固件版本也会影响。主板芯片组驱动过旧，可能导致虚拟化能力没有被正确上报；固件版本过旧，可能对 Win11 的电源管理支持不完整，间接影响虚拟化状态的保持。这类问题不常见，但在一些老平台升级 Win11 的机器上确实遇到过。判断方法是对比同一台机器在别的系统下的表现，如果别的系统正常、只有 Win11 出问题，就优先怀疑系统功能和驱动，而不是硬件坏了。

3. 动手实操：按顺序把每一个坑填掉

3.1 固件设置的完整操作与验证

先从固件开始。关机，拔掉外设，开机后立刻连按进固件的按键，进入设置界面。如果你不确定按键，可以在开机第一屏出现厂商 Logo 时留意屏幕下方的提示，通常会写“Press XXX to enter Setup”。进入后，如果是简易模式，先切换到高级模式，再找 CPU 配置相关的菜单。找到虚拟化选项，设为 Enabled，同时把 VT-d 或 IOMMU 一并打开，保存并退出。

重启进入系统后，立刻做三项验证。第一项，任务管理器看“虚拟化”是否显示“已启用”。第二项，msinfo32 看“基于虚拟化的安全性”的状态，这时候它可能仍然显示“正在运行”，因为系统的安全功能还在占用，这不代表固件没开。第三项，用管理员终端执行一条查询处理器虚拟化固件状态的命令，输出里会明确告诉你固件是否已启用虚拟化、是否支持二级地址转换。三项都对得上，说明固件这一层没问题，可以往下走。

注意：改固件设置前，如果机器开了设备加密，建议先确认恢复密钥可用，避免改完启动配置后要求输入密钥却找不到。

3.2 关掉冲突的 Windows 功能，顺序有讲究

系统功能这一层，推荐用“先图形、后命令”的顺序。图形界面里，打开“启用或关闭 Windows 功能”，把 Hyper-V、虚拟机平台、Windows 沙盒、容器这几项取消勾选，确定后按提示重启。然后在 Windows 安全中心里，进入“设备安全性”，点“内核隔离详细信息”，把内存完整性关掉，再重启一次。两次重启不要合并，因为功能卸载和内核隔离关闭的生效时机不一样，合并重启有时会出现状态没刷新干净的情况。

如果图形界面里找不到某些项，或者关了之后又自动回来，就用命令行补刀。以管理员身份打开终端，依次执行查询和关闭命令。查询当前 Hyper-V 相关功能状态，可以用系统自带的部署映像服务工具列出功能信息；关闭时用对应的禁用命令，加上不重启参数，全部执行完再统一重启。还需要检查启动配置里虚拟机监控程序的加载方式，把它设为不加载，这一步是很多教程漏掉的，只关功能不改启动项，系统仍可能在启动早期加载监控程序。

:: 查询 Hyper-V 相关功能状态（管理员终端） dism /online /get-featureinfo /featurename:Microsoft-Hyper-V-All :: 关闭 Hyper-V 全家桶、虚拟机平台、沙盒、容器 dism /online /disable-feature /featurename:Microsoft-Hyper-V-All /norestart dism /online /disable-feature /featurename:VirtualMachinePlatform /norestart dism /online /disable-feature /featurename:Containers-DisposableClientVM /norestart dism /online /disable-feature /featurename:Containers /norestart :: 关闭启动时的虚拟机监控程序加载 bcdedit /set hypervisorlaunchtype off

执行完重启，再用 msinfo32 看“基于虚拟化的安全性”是否变成“未启用”。如果还是“正在运行”，说明还有别的安全功能在撑着，比如凭据保护或者某种由策略下发的配置，这时候要往组策略或设备管理方向查。需要提醒的是，bcdedit这条命令改的是启动项，属于系统级配置，改之前记下原值，想恢复的时候执行bcdedit /set hypervisorlaunchtype auto再重启即可。如果你平时用 WSL2 或 Docker，关掉这些之后它们会无法启动，这是预期行为，不是弄坏了。

3.3 编辑 .vmx 配置文件的关键参数

图形界面和系统功能都调完之后，如果还报错，就要动配置文件了。先完全退出 VM 软件，包括托盘图标里的后台进程，然后找到虚拟机目录。默认位置一般在用户文档目录下的虚拟机文件夹里，每台虚拟机一个子目录，里面除了磁盘文件，还有一个与虚拟机同名的 .vmx 文件。把它复制一份改名备份，再用记事本或别的纯文本编辑器打开。

这个文件里是一行一个键值对，格式是“键 = 值”。跟虚拟化相关的关键项有这么几个。控制嵌套虚拟化的项，决定虚拟机内部能不能再跑虚拟机，值设为 TRUE 时，VM 软件会向宿主机申请更完整的虚拟化能力，如果你的宿主机本身虚拟化资源紧张，这一项反而可能加重报错，所以非必要不要开。控制是否向虚拟机隐藏监控程序存在的项，某些软件在检测到自己在虚拟机里会拒绝运行，把这一项设为 FALSE 可以隐藏这层信息，但它不解决宿主机拿不到虚拟化能力的问题，属于另一种用途。还有内存相关的兼容项，老系统或特殊系统才需要，普通 Win11 虚拟机不用动。

vhv.enable = "TRUE" hypervisor.cpuid.v0 = "FALSE" mce.enable = "TRUE"

上面三行只是示例，不同软件版本支持的参数名不完全一样，照抄之前先确认自己的版本。改的原则是：只加自己明确知道用途的行，不要从网上整段复制一堆参数进去。改完保存，注意文件编码保持原样，不要存成带 BOM 的格式，也不要用 Word 这类富文本编辑器打开，否则可能引入不可见字符，导致软件读不懂配置。启动虚拟机后，去虚拟机目录下找日志文件，搜索与虚拟化、监控程序相关的关键字，能看到这次启动到底走了哪条路径，是硬件直通模式还是兼容模式，日志里的信息比弹窗详细得多。

3.4 权限、兼容性与版本升级

配置文件改完还是不行，就检查运行权限。VM 软件需要加载内核级驱动来接管硬件，普通用户权限下有些操作会失败。右键软件图标，选择“以管理员身份运行”，再启动虚拟机试试。如果这样能起来，说明是权限问题，可以在软件的可执行文件属性里设置“始终以管理员身份运行”，但这会带来每次启动都弹权限确认的麻烦，权衡一下。

版本问题更常见。打开软件的帮助菜单看版本号，对照官方文档里对 Win11 的支持说明。如果版本落后一个大版本以上，直接升级。升级前把虚拟机关机，不要挂起，升级后第一次启动可能会提示更新虚拟机硬件兼容性，按提示走就行。升级完如果问题依旧，可以试着用软件的兼容性选项，把运行模式调整为适配新系统的模式，具体入口在不同版本里位置不一样，一般在首选项的兼容性设置里。

还有一个细节：如果你之前装过多个版本的 VM 软件，残留的旧驱动可能还在系统里，导致新版本加载了错误的驱动。这种情况的典型表现是软件能打开、虚拟机也能建，但一开机就报虚拟化错误。处理方法是彻底卸载所有版本，重启，再装最新版。卸载时留意安装程序有没有提供“清除配置和驱动”的选项，有就勾上。

3.5 怎么验证真的修好了

修好之后不要只看“能开机”就完事，要做三项验证。第一项，看任务管理器里虚拟机的 CPU 占用是否正常，如果开机后 CPU 长期跑满、操作明显卡顿，说明走的是软件模拟或兼容模式，虚拟化能力并没有真正拿到。第二项，在虚拟机里执行一条查看系统信息的命令，看它报告的处理器特性里有没有虚拟化相关项，有就说明嵌套能力也通了。第三项，回到宿主机的虚拟机日志，确认这次启动用的是硬件虚拟化模式，而不是回退模式。

如果三项都正常，再做个压力测试：在虚拟机里编译一个稍大的项目，或者跑一段磁盘读写，观察宿主机的资源占用是否平稳。硬件虚拟化下，虚拟机的磁盘和网络性能应该接近物理机的一半以上；如果只有个位数百分比，那还是没修彻底。这一步能帮你区分“报错消失了”和“问题真的解决了”，很多人卡在前者，用起来才发现慢得离谱。

4. 常见问题速查与排查技巧

4.1 高频问题对照表

4.2 几个反直觉的坑

第一个坑是“关了但没完全关”。Windows 的功能卸载和启动项修改是两套机制，功能关了，启动项还在，系统启动时照样加载监控程序。判断方法是看 msinfo32 里的状态，不要只看功能列表里的勾选状态。第二个坑是“重启方式不对”。Win11 默认的关机再开机，因为快速启动的存在，并不是完整的冷启动，某些内核级配置不会重新加载。改完虚拟化相关设置后，建议用“重启”而不是“关机再开”，或者在电源选项里临时关闭快速启动。

第三个坑是“安全软件静默拦截”。某些安全软件会在后台阻止对系统功能的修改，你点了关闭，它给你改回来，界面上还不提示。表现是每次重启后状态又变回去。排查方法是临时退出安全软件再操作，或者查看它的防护日志。第四个坑是“虚拟机挂起状态”。如果你是在虚拟机挂起的情况下改的宿主机配置，恢复时可能读到旧的硬件状态，报错依旧。改配置前先把虚拟机关机，不要挂起。

第五个坑是“版本回退”。有时候升级完软件问题反而更多，想回退旧版本，但旧版本的驱动和新系统不兼容，回退后报错换了张脸。这种情况建议不要反复横跳，选定一个官方明确支持当前系统的版本，把系统侧的功能配置调到位，比换版本更靠谱。

4.3 关掉安全功能之后的性能与安全权衡

这一节说点实在的。关掉内存完整性和系统自带的监控程序，虚拟机的性能确实会回来，但机器的安全基线也降了一档。内存完整性的作用是阻止恶意代码篡改内核结构，关掉之后，某些类型的攻击面会变大。我的建议是分机器处理：如果这台机器专门用来做开发测试、跑虚拟机、折腾各种环境，关掉换取性能可以接受，但不要在这台机器上存放敏感资料，也不要用来处理不信任的邮件附件；如果是日常办公主力机，宁可让虚拟机跑在兼容模式，慢一点但安全边界完整，或者干脆把虚拟机放到另一台机器、另一块硬盘上的独立系统里。

还有一个折中方案：需要跑虚拟机的时候临时关闭，跑完再打开。听起来麻烦，但如果你只是偶尔用一次虚拟机，这个成本并不高。可以把这个过程写成一个小清单，每次按清单操作，避免漏步骤。我不建议为了省事去写自动切换脚本，因为这类脚本涉及系统启动配置和内核安全功能，一旦逻辑写错，可能导致系统起不来，恢复成本远高于手动操作。

5. 长期维护：让这个问题不再反复出现

5.1 给机器建一份虚拟化状态清单

我现在习惯在每台常用机器上留一份简短的状态记录，内容包括：固件里虚拟化选项的名称和当前状态、系统里 Hyper-V 相关功能是否开启、内存完整性是否开启、VM 软件版本号、以及每次改动的日期和原因。这份记录不需要多正式，一个文本文件就够。它的价值在于，下次再遇到同样的报错，你不用从头猜，直接对照记录看哪一项变了。Windows 更新、安全软件升级、装新开发工具，这三件事是最容易悄悄改变虚拟化状态的，有了清单，排查时间能从半小时压缩到几分钟。

记录里还可以加上一条“本机用途”：是纯开发机、还是办公机、还是双系统里的一个分区。用途决定了取舍方向，写下来能避免自己在“关不关安全功能”之间反复纠结。我见过太多人因为没想清楚用途，今天关明天开，最后把系统配置搞得一团乱。

5.2 装新软件前先问一句“它要不要虚拟化”

WSL2、Docker Desktop、Windows 沙盒、安卓子系统、部分模拟器、部分带沙箱的浏览器，这些工具在安装时都可能把虚拟机平台拉起来。安装前先想一下：这台机器上还要不要跑 VM 软件？如果要，就得提前规划好谁让谁。可行的做法是给不同用途分机器或分系统，比如日常办公用主系统，虚拟机和学习环境放在另一块硬盘的独立系统里，两边互不干扰。实在要在一台机器上共存，就接受 VM 软件走兼容模式的性能损失，不要指望既开着一堆依赖虚拟化的功能，又让虚拟机跑出满血性能。

5.3 嵌套虚拟化和共存模式，什么时候该放弃

嵌套虚拟化指的是在虚拟机里再跑虚拟机，常见于学习容器、测试集群、做实验环境。它需要宿主机把 VT-x 和 EPT 能力透传给虚拟机，对硬件和软件版本都有要求，性能损耗也很明显，通常只有物理机的一半甚至更低。如果你只是偶尔在虚拟机里跑个 Docker，可以开；如果是长期使用，建议直接把那套环境搬到物理机或者独立机器上，别在嵌套里硬扛。

共存模式也是同理。让 VM 软件和系统自带监控程序共存，技术上可行，但代价是虚拟机性能打折，而且不同版本表现差异很大。我的判断标准很简单：如果虚拟机的用途是“偶尔开一下、跑个轻量系统”，共存模式可以接受；如果用途是“长期跑编译、跑数据库、跑测试”，那就应该把系统侧占用的功能关掉，或者换一台机器。不要为了省一台机器的钱，把每天的工作效率搭进去。

最后分享一个我自己的习惯：每次动完虚拟化相关配置，我都会在虚拟机里跑一个固定的基准测试，记录下分数和耗时。这个数字比“感觉快了”可靠得多，也能在下次出问题时快速判断是配置退化还是心理作用。配置这东西，改的时候觉得都记得，过两个月全忘光，留个数字，比留一堆笔记都管用。