简介dgreadiness_v3.6 是一套面向 VMware 虚拟化运维与 Windows 系统管理人员的检测工具核心用途是检查并修复虚拟机在虚拟化平台上的运行状态与合规配置。它由 PowerShell 脚本驱动可依据内置的审计与强制策略评估硬件辅助虚拟化是否启用、操作系统是否满足虚拟化支持条件以及是否存在影响性能或兼容性的配置偏差适合环境预检、上线前巡检与故障排查等场景。压缩包共 6 个文件、约 31KB以 2 个 xml 策略配置、2 个 p7b 安全策略证书、1 个 PowerShell 脚本和 1 个 ReadMe 说明为主脚本承担检测逻辑XML 与 p7b 文件承载审计与强制两类策略ReadMe 则交代使用前须知。目前已有 4212 人学习下载。读者可直接运行脚本为目标主机做一次策略化体检并对照两份策略文件理解审计与强制两种模式的差异将检测结论落实为具体的配置修正动作减少虚拟化环境中的调试试错。1. 虚拟化跑不起来那句“此主机不支持 64 位客户机”到底在说什么虚拟化运行状态出问题大多数人是在装虚拟机装到一半时撞上的弹窗提示此主机不支持 64 位客户机操作系统或者干脆说 VT-x 处于禁用状态。你回头打开任务管理器性能页上“虚拟化”那一行写着“已禁用”。明明是支持虚拟化的 CPUBIOS 里也没印象动过什么重启三次得到的还是同一句提示。这类故障卡住的不是一个小功能而是整条工作流——本地调试环境、镜像构建、多系统并存的测试全都得排队等它。折腾过的人都知道虚拟化报错难受的地方不在解决难度而在信息量太少一句“不支持”背后可能是固件开关没打开、可能是系统里另一个 hypervisor 先把 VT-x 占了、也可能真的是主板或平台锁死。把这三层拆开看事情才有解。2. 固件层的红灯任务管理器显示“已禁用”BIOS 里却明明是开的固件层是排查顺序里的第一站也是被误判最多的一站。很多人一看任务管理器写着“已禁用”立刻重启进 BIOS把 Virtualization Technology 打开保存退出回来一看——还是禁用。于是开始怀疑主板坏了、CPU 不支持。实际上一台机器上“虚拟化”这个词至少对应三样东西CPU 的硬件虚拟化扩展Intel 叫 VT-xAMD 叫 SVM、芯片组的 IOMMU 重映射Intel 的 VT-d、AMD 的 IOMMU、以及固件把这些能力交给操作系统的方式。三者任意一环没打通上层拿到的结论都可能是“不支持”。2.1 先用一条命令把固件状态问清楚别靠猜在 Windows 上最省事的入口是 WMI不需要装任何额外工具也不用进 BIOS 反复重启。管理员权限打开 PowerShell跑下面这段# 一次性问清三件事CPU 有没有虚拟化扩展、固件有没有打开开关、系统里是否已有 hypervisor 在运行 Get-CimInstance Win32_Processor | Select-Object Name, VMMonitorModeExtensions, # VT-x / AMD-V 硬件能力 SecondLevelAddressTranslationExtensions, # EPT / NPT二级地址转换 VirtualizationFirmwareEnabled # 固件是否已放行 # 是否有 hypervisor 正在占用虚拟化扩展 (Get-CimInstance Win32_ComputerSystem).HypervisorPresent三个布尔值的组合基本能把情况定死不用再猜VMMonitorModeExtensionsVirtualizationFirmwareEnabledHypervisorPresent结论TrueTrueFalse固件层已通问题在别处往下看第 3 章TrueFalseFalse固件开关没开进 BIOS 打开 VT-x / SVMTrueTrueTrue已被某个 hypervisor 独占去关冲突项False任意任意CPU 本身不支持或虚拟机被宿主平台限制了嵌套虚拟化VMMonitorModeExtensions读的是 CPUID 里的能力位是硬件事实改不了VirtualizationFirmwareEnabled读的是固件把控制权交没交给 OS取决于 BIOS/UEFI 设置HypervisorPresent表示当前已经有一层 hypervisor 在跑这时候第三方虚拟化软件通常拿不到根权限。这三者的区别一定要分清很多人把第二项当成第一项白白换了一轮内存条。Linux 侧对应的检查更直接一行 grep 就够# 统计 CPU 暴露的虚拟化扩展数量结果为 0 说明固件没开或 CPU 不支持 grep -c -E (vmx|svm) /proc/cpuinfo # 更可读的方式看 Virtualization 一行 lscpu | grep -i virtualizationvmx是 Intel 的标志svm是 AMD 的标志两个都没出现就说明内核根本没看到虚拟化扩展。注意这里有个常见误判某些发行版在lscpu里会把Virtualization: VT-x显示成硬件能力而不是开关状态看到 VT-x 就以为已经启用其实固件照样关着。以/proc/cpuinfo的 flags 为准更稳。2.2 VT-x 和 VT-d 不是一个开关开错照样报错主板 BIOS 里通常有两到三个相关选项名字各家不同但功能分得清Virtualization Technology / Intel VT-x / SVM ModeCPU 硬件虚拟化装 64 位虚拟机必须开。VT-d / IOMMU设备直通用的 DMA 重映射不做 PCI 直通可以先不开但开了对稳定性有好处。Trusted Execution Technology / 各种安全启动子项跟虚拟化没直接关系但某些固件在开启安全启动后会限制 hypervisor 加载。血泪经验是只开 VT-d 不开 VT-x 的机器是存在的因为有些主板把两项做在同一个菜单下名字又起得含糊勾了一个以为全开了。判断办法很简单——跑完 2.1 的命令看VMMonitorModeExtensions是不是 True是 True 才说明 CPU 能力被固件放行了跟 VT-d 开没开没关系。还有一类情况容易被忽略品牌机、一体机、部分笔记本的固件里虚拟化选项是隐藏的需要在特定条件下才会出现或者被厂商的整机管理策略锁定。这种时候VirtualizationFirmwareEnabled会稳定返回 False你怎么找菜单都找不到。常见做法是先去厂商支持页确认该型号是否开放该选项而不是盲目刷 BIOS。2.3 云主机和嵌套虚拟化这一层的坑不在你手里如果报错出现在云主机、远程桌面上判断逻辑要换一套。绝大多数云主机默认不给你嵌套虚拟化VMMonitorModeExtensions直接就是 False无论你怎么改固件设置都没用——因为 CPUID 是宿主层过滤过的。这种情况下唯一的出路是换支持嵌套虚拟化的实例规格或者在本地完成需要虚拟化的工作再同步过去。判断方法先看(Get-CimInstance Win32_ComputerSystem).Model和厂商信息确认是不是虚拟环境如果是就不要在固件层浪费时间了直接联系平台确认实例是否开启嵌套。我一般会先跑一遍检测工具看到报告里“固件支持”和“CPU 扩展”两项同时为否且机型字段是虚拟机型就直接跳过 BIOS 排查。固件层排查完了还没解决说明问题大概率不在硬件开关上而在操作系统内部的资源争抢——这才是虚拟化运行状态出错最常见、也最绕的一层。3. 关掉 hypervisor 仍然起不来bcdedit 与内存完整性这两条线固件层确认无误后第二站是操作系统。Windows 从 10 开始自带 hypervisor而且越来越多的安全功能建立在它之上。问题在于VT-x 这类硬件虚拟化扩展是独占资源一层 hypervisor 拿到根权限后其他虚拟化软件只能以客户机身份运行或者干脆被拒绝。表现出来就是那句经典的“此主机不支持虚拟化”明明固件开着系统偏说没有。3.1 hypervisorlaunchtype 是第一现场先看再改启动项里有个开关决定 Windows 是否在引导阶段加载 hypervisor默认在部分版本上是 auto。查它# 管理员权限的 cmd 中执行查看当前启动项的 hypervisor 加载策略 bcdedit /enum {current} | findstr /i hypervisorlaunchtype # 关闭重启后 Windows 不再抢占 VT-x bcdedit /set hypervisorlaunchtype off # 需要恢复时改回 auto bcdedit /set hypervisorlaunchtype auto{current}指当前启动项多系统机器上要确认改的是你实际启动的那一个否则会出现“明明改了却没生效”的情况。off是彻底不加载auto是交给系统判断。改完必须完整重启关机再开机不算——快速启动模式下的“关机”是休眠配置不会重新加载这个坑我踩过不止一次。改完再跑一次(Get-CimInstance Win32_ComputerSystem).HypervisorPresent返回 False 才说明生效。如果仍然是 True说明还有别的东西在拉起 hypervisor继续往下看。3.2 内存完整性和基于虚拟化的安全性会静默抢走 VT-x从 Windows 10 1803 之后Windows 安全中心里多了“内核隔离 - 内存完整性”这个功能本质上是基于虚拟化的安全性VBS它自己就要跑一层 hypervisor。很多人bcdedit改完 off重启后HypervisorPresent又是 True就是被它拉起来的。查它# 查看 VBS 整体状态0 关闭1 已启用但未运行2 正在运行 Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard | Select-Object VirtualizationBasedSecurityStatus, SecurityServicesRunning, SecurityServicesConfiguredSecurityServicesRunning里如果出现 1Credential Guard或 2HVCI即内存完整性基本可以确定是它占着。对应的开关在两个地方# 查内存完整性是否开启Enabled 1 表示开启 reg query HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity /v Enabled图形界面的路径是 Windows 安全中心 → 设备安全性 → 内核隔离详细信息 → 内存完整性关掉后重启。命令行改注册表也行但要注意部分设备被组织策略托管时改完会被策略重新写回去这时候得从策略层解决硬改注册表只会反复横跳。提示关闭内存完整性会降低系统对内核级恶意代码的防护能力如果这台机器是长期在用的主力机建议在需要跑虚拟化的时段临时关用完再打开而不是永久关掉。同样会抢占的还有 Windows 自带的虚拟机平台组件。它们挂在“启用或关闭 Windows 功能”里用一条命令能全列出来# 列出所有可能拉起 hypervisor 的 Windows 功能及其当前状态 Get-WindowsOptionalFeature -Online | Where-Object { $_.FeatureName -match Hyper-V|VirtualMachinePlatform|WindowsSandbox|Linux } | Select-Object FeatureName, State关注四项Microsoft-Hyper-V-All完整 Hyper-V、VirtualMachinePlatform虚拟机平台WSL2 依赖它、Containers容器、Containers-DisposableClientVMWindows 沙盒。只要其中任意一项是 EnabledVT-x 就可能被占用。注意 WSL2 一旦装了VirtualMachinePlatform就是开着的关掉它 WSL2 会失效——这是个取舍不是纯粹的“修好”。3.3 关完之后残留的虚拟网卡与驱动还有一种情况配置都改对了HypervisorPresent也是 False但虚拟化软件启动时仍然报错。这时候要看的是驱动和虚拟网卡残留。卸载 Hyper-V 或虚拟机平台后Get-NetAdapter里可能还挂着几个隐藏的虚拟适配器设备管理器里也残着虚拟交换机驱动。# 列出所有网络适配器包括已断开的隐藏项 Get-NetAdapter -IncludeHidden | Select-Object Name, InterfaceDescription, Status # 查看是否有残留的虚拟交换机 Get-VMSwitch -ErrorAction SilentlyContinue处理顺序是先在“设备管理器 → 查看 → 显示隐藏的设备”里把灰色残留的虚拟适配器卸干净再检查网络连接里有没有指向不存在设备的虚拟网卡。残留的虚拟交换机有时会让虚拟化软件在初始化网络桥接阶段失败而报错文案却仍然指向“虚拟化不可用”误导性极强。系统层这三条线走完绝大多数“固件明明开着、系统偏说不支持”的故障都能定位。剩下的就是怎么快速确认自己到底卡在哪一层——这正是检测工具存在的意义。4. 读检测报告把 dgreadiness 的输出逐项对上处理动作手工一条条跑命令当然可行但排查的时候人容易漏项查了固件忘了查 VBS关了 hypervisor 忘了看残留驱动。检测工具的价值不在“替你解决”而在把散落在 WMI、注册表、启动项、可选功能里的状态一次性抓齐让你一眼看到底是哪一层亮红灯。dgreadiness_v3.6 做的就是这件事——把虚拟化运行状态的判断拆成可对照的检查项输出一份能直接对着处理的结果而不是甩给你一句“不支持”。4.1 报告里哪几行才是真结论一份典型的检测输出会分成三块硬件与固件能力、系统层占用情况、环境与限制条件。读的时候不要从头往下顺先抓三条主线的判定结果剩下的都是佐证。第一块看 CPU 扩展与固件开关。这两项同时为真硬件层就通了后面再怎么报错都不是 CPU 的问题。只要固件项为假无论其他项多漂亮都得回 BIOS。第二块看“已被占用”这类结论。它对应的就是第 3 章里那些 hypervisor 来源启动项策略、VBS、虚拟机平台组件。报告里如果出现“检测到已有 hypervisor 运行”的判定说明矛盾的根源在系统层不在固件。第三块看环境标识是不是运行在虚拟机里、系统版本是否满足要求、内存与磁盘是否够跑目标客户机。这部分不解决“报错”但能解释一批看起来莫名其妙的失败——比如在云主机上死磕固件设置或者在内存不足的机器上反复怀疑虚拟化没开。我把这三块的判断顺序固定成能力 → 占用 → 环境。先确认能力有没有再看被谁占了最后看环境允不允许。顺序颠倒就会绕路先查环境的往往查半天才发现是固件没开。4.2 三类红灯分别对应什么动作把常见红灯归成三类处理动作是固定的不用每次重新推理红灯类型典型判定处理动作是否需要重启固件未放行硬件支持但固件开关关闭进 BIOS 打开 VT-x / SVM保存退出是被 hypervisor 占用检测到已有虚拟化层在运行关启动项策略、关 VBS、停用虚拟机平台是环境不支持运行于虚拟环境且未开嵌套更换实例规格或改到本地执行否需换环境第三类最容易被误判成前两类。有人拿到“环境不支持”的判定仍然去改 BIOS、关 VBS折腾两小时毫无进展。判断办法很简单报告里如果明确标出当前系统运行在虚拟化平台上而目标又是再跑一层虚拟机那这就是嵌套虚拟化的问题本地配置怎么改都没用。注意检测报告是快照不是实时监控。改完配置必须重新跑一次用新报告确认红灯变绿而不是凭感觉认为“应该好了”。我见过太多“我改过了”——改的可能是另一个启动项或者根本没重启。4.3 让检测结果可复现把报告存下来做基线单次检测只能回答“现在是什么状态”。真正省时间的是留基线机器刚装好、一切正常的时候跑一次把输出存成文件以后出问题跑一次新的两份对着看差异根因往往就藏在那一两行的变化里。# 以管理员权限运行把报告重定向到文件方便和基线对比 dgreadiness.exe readiness-baseline.txt 21 # 出问题时再跑一次 dgreadiness.exe readiness-now.txt 21 # 对比两份报告只看差异行 diff -u readiness-baseline.txt readiness-now.txt file 21把标准输出和错误输出一起重定向避免关键报错落在控制台没被记下来。文件名带上日期更好比如readiness-20240612.txt时间线一目了然。对比时重点关注能力项和占用项的变化环境项一般不会无缘无故变。这套流程听着笨但在多台机器、多人协作的场景下非常值出了问题不用远程指挥对方一条条敲命令让他把两份报告发过来差异一比对八成能直接说出该改哪里。这也是检测工具相对于手工排查最大的价值——它把“状态”变成了可传递、可存档的东西。5. 避坑记录五个让排查绕远路的细节排查虚拟化故障最耗时间的从来不是改配置而是被错误信息带到错误的方向上。下面五条是我在实际处理里反复遇到的每一条都能让排查多绕半小时以上。5.1 改了 bcdedit 没重启以为没生效现象执行bcdedit /set hypervisorlaunchtype off后立刻跑检测HypervisorPresent依然是 True判定为“命令无效”转而怀疑权限或系统损坏。原因bcdedit改的是下次引导的加载策略当前运行的内核不会因为命令执行而卸载已经加载的 hypervisor。更隐蔽的是 Windows 的快速启动——很多人点“关机”再开机系统其实是走休眠恢复路径引导配置根本没重新读取。解决一律用“重启”而不是“关机再开”并且重启后重新执行bcdedit /enum {current} | findstr hypervisorlaunchtype确认值为 off再用HypervisorPresent二次验证。两个结果都对了才算生效。5.2 关了内存完整性注册表值却还是 1现象在 Windows 安全中心把内存完整性关掉并重启用reg query查HypervisorEnforcedCodeIntegrity的 Enabled 仍然是 1检测报告继续报“VBS 运行中”。原因这台机器被组织策略托管安全中心里的开关是灰的或者被策略覆盖界面上点了“关闭”但策略在下次登录时又写了回去。这种情况下界面操作是假动作。解决先确认是不是被托管——Get-CimInstance -Namespace root\Microsoft\Windows\DeviceGuard -ClassName Win32_DeviceGuard看配置来源或者检查组策略结果。托管设备需要从策略层调整硬改注册表会被覆盖改完还会让你误以为方法无效。5.3 只关了 Hyper-V忘了 WSL2 的虚拟机平台现象Hyper-V 功能已经卸载检测报告仍然显示有虚拟化层在运行虚拟化软件照旧起不来。原因WSL2 依赖VirtualMachinePlatform这个功能独立于 Hyper-V卸载 Hyper-V 不会带走它。装了 WSL2 的机器上这一项默认是 EnabledVT-x 一直被占着。解决用Get-WindowsOptionalFeature -Online把四项一起查别只盯着 Hyper-V。要保留 WSL2 就得接受它和第三方虚拟化软件的冲突要么改用 WSL1要么在需要虚拟化的时段临时停用这中间没有两全的配置。5.4 在云主机上死磕固件设置现象远程机器上检测硬件能力项为真、固件项为假于是反复联系机房、找 BIOS 菜单折腾半天发现根本没有固件设置入口。原因云主机跑在别人的 hypervisor 上暴露给你的是过滤后的 CPUID固件层根本不归你管。看到“固件未放行”不等于“你去打开就行”。解决第一步先判断环境——看机型字段、看是否为虚拟化平台。确认是云主机就直接跳到嵌套虚拟化的话题不要在 BIOS 上耗时间。本地物理机才走固件排查逻辑。5.5 卸载不彻底残留虚拟网卡继续干扰现象所有配置都对检测报告全绿虚拟化软件启动仍然报网络初始化失败错误文案却泛泛指向虚拟化不可用。原因卸载 Hyper-V 或虚拟机平台后隐藏的虚拟适配器和虚拟交换机驱动留在系统里虚拟化软件在桥接网络阶段碰到它们就失败报错信息被上层统一成了“虚拟化不可用”。解决设备管理器里显示隐藏设备把灰色残留的虚拟适配器清掉Get-VMSwitch确认没有残留交换机必要时用系统自带的网络重置。清理完再跑一次检测确认报告里的网络相关项没有异常。6. 快速定位三分钟判断问题在固件、系统还是硬件真到了现场最需要的不是把所有命令都跑一遍而是一条能快速分流的判断路径。我的习惯是三步走每步只回答一个问题答完立刻决定下一步去哪儿不做无关排查。第一步问“硬件能力有没有”。跑一次 CPU 扩展和固件开关的查询两项都真就直接进第二步任意一项为假就先分清是 CPU 不支持还是固件没开——VMMonitorModeExtensions为假是硬件或宿主限制VirtualizationFirmwareEnabled为假才是固件开关的事。这一步做完能排掉大约一半的误判。第二步问“被谁占了”。HypervisorPresent为真就继续追顺序固定启动项策略 → VBS 与内存完整性 → Windows 可选功能。三处查完基本能锁定来源。这里有个提速技巧不要一个个开关试直接用检测工具一次性抓齐再对着报告里的红灯项处理。第三步问“环境允不允许”。如果前两步都正常还起不来或者报告明确标出当前运行在虚拟化平台上那就别再折腾本地配置了去确认嵌套虚拟化支持情况。把这三步压成一张对照表贴在排查笔记里最省事现象优先排查方向一条命令验证提示 VT-x 禁用任务管理器也显示禁用固件开关(Get-CimInstance Win32_Processor).VirtualizationFirmwareEnabled固件已开仍提示不支持hypervisor 占用(Get-CimInstance Win32_ComputerSystem).HypervisorPresent改了 bcdedit 无效是否完整重启bcdedit /enum {current} | findstr hypervisorlaunchtype报告全绿但启动失败驱动与虚拟网卡残留Get-NetAdapter -IncludeHidden云主机上始终不支持嵌套虚拟化查机型字段确认是否为虚拟环境验证环节同样要有固定动作不能靠“感觉好了”。改完配置后按这个顺序复核先跑检测拿新报告确认红灯项转绿再启动一次目标虚拟化软件走到能创建并启动客户机为止最后看一眼事件查看器里有没有虚拟化相关的错误记录残留。三步都过才算真的修好。只做第一步很容易出现“报告绿了但实际跑不起来”的假修复尤其是 5.5 那种残留驱动的情况。还有个小习惯值得养成每次动配置之前先把当前状态存一份。改坏了能回退改好了有对比改到一半被人打断回来也知道自己走到哪儿了。这份基线文件在多人协作时更好用——别人报故障你让他发报告而不是描述现象描述永远丢细节。从那以后我每台新机器到手第一件事就是跑一遍检测把报告存成基线文件配置变更前再存一份。踩过的坑告诉我虚拟化这块的报错文案可信度很低真正可信的只有命令返回的那几个布尔值。希望帮到你。本文还有配套的精品资源点击获取