简介这是一份面向 VMware 虚拟化运维人员的虚拟化就绪检测工具包主要解决虚拟机运行状态异常、虚拟化功能未正确启用等问题。包内提供 PowerShell 主脚本配合 XML 策略文件与 p7b 安全策略文件可自动检查并修复硬件辅助虚拟化、系统兼容性等关键配置帮助虚拟机在 VMware 平台上更稳定高效地运行。资源共 6 个文件包含 ps1 脚本、xml 配置、p7b 证书策略和 txt 说明文档整体仅 31KB轻量易用。建议使用前先阅读 ReadMe.txt再按需执行 DG_Readiness_Tool_v3.6.ps1 进行审计或强制策略应用。该资源已有 4156 人学习下载适合需要快速排查虚拟化状态、完善虚拟机合规配置的 VMware 管理员参考。 有一次我在一台国产化服务器上部署天逸终端虚拟化平台镜像都推完了结果管理端一直报“虚拟化运行状态异常”。物理机的 CPU 明明支持虚拟化型号也没问题可平台死活不认。折腾了小半天最后靠 dgreadiness_v3.6 跑了一次环境检查几分钟就定位到了根因——处理器虚拟化扩展在固件层被关掉了操作系统里根本拿不到完整的虚拟化能力。类似的场景这两年特别多Docker 无法开启虚拟化、WSL2 启动提示没有启用虚拟化、ESXi 服务器上报虚拟化异常、虚拟机里再跑虚拟化平台时报 CPU 不支持……表面上报错五花八门根子上往往是同一个问题虚拟化运行状态不正常。今天我就以 dgreadiness_v3.6 为主线把这类问题的排查思路、修复方法以及我在实战中踩过的坑完整梳理一遍。文章会从工具定位讲起再到症状识别、分层排查、具体修复最后是避坑经验适合正在部署虚拟化平台、或者被虚拟化报错折磨的运维和开发朋友参考。1. dgreadiness_v3.6 的定位它解决的是“运行状态”不是硬件兼容性1.1 从工具名理解它的职责第一次看到 dgreadiness_v3.6 这个名字容易误以为是某个“全家桶”安装包。其实 readiness 这个词已经把它的核心职责写明白了——这是一个就绪性检查工具回答的问题非常具体当前这台机器到底能不能按预期方式把虚拟化跑起来。v3.6 这个版本号的背后是检查逻辑的一次重要调整。早期版本更多聚焦“硬件支不支持虚拟化”这个静态维度比如 CPU 是否带 VMXIntel或 SVMAMD扩展标志位。但实际环境里绝大多数现代 CPU 都带虚拟化扩展光看硬件标志根本解决不了问题。真正卡人的是另一类状态硬件支持但当前运行状态不允许调用。固件把开关关了、系统里 VBS 把虚拟化占用了、宿主机没把嵌套虚拟化透传进虚拟机这些才是高频根因。dgreadiness_v3.6 的检测重心正好落在这类运行状态问题上。我用它的时候最明显的感觉是检测项不是孤立地报 PASS/FAIL而是把 CPU 特性、固件配置、系统内核参数、驱动状态串成一条链路来核对哪一环断了报告里会给出具体说明。这比很多只会说“不支持”的检测脚本友好得多。1.2 它和“去虚拟化工具”不是一回事搜虚拟化资料时经常会关联到 vmware 去虚拟化、去虚拟化工具、虚拟化修改 CPU 型号这些词。这里要先说清楚dgreadiness_v3.6 和这类工具完全不是一路。去虚拟化工具做的是“隐藏虚拟化特征”把虚拟机里的 CPU 型号、主板信息、ACPI 表改成接近物理机的样子让某些软件检测不到虚拟化环境的存在。这类工具有它的灰度用途也有明确的合规风险我不展开讨论。dgreadiness 走的是完全相反的方向它的目标是确认虚拟化能力确实存在且能被系统正常调用。它不隐藏任何东西反而要把虚拟化相关的底层状态全部翻出来核对。简单说一个在解答“怎么让软件以为我不是虚拟机”另一个在解答“怎么让虚拟化平台能稳定运行”。方向如果搞反了用检测工具去处理本应改固件的场景问题只会越拖越久。1.3 哪些场景会真正用到它根据我这些年的经验高频用到这类检测工具的场景大概有四类。服务器虚拟化平台部署前预检在物理服务器上装 ESXi、KVM 或国产虚拟化平台比如麒麟天逸终端虚拟化平台之前先跑一遍检查避免装到一半才发现 CPU 虚拟化没开。嵌套虚拟化确认在 VMware Workstation 或 VirtualBox 里跑虚拟化平台测试环境时确认宿主机是否把硬件辅助虚拟化透传给了虚拟机。运行中异常定位平台本来跑得好好的突然某天管理端提示虚拟化运行状态异常用工具快速定位是固件被重置还是系统补丁把虚拟化关了。应用兼容性排查WSL2、Docker Desktop、模拟器这类依赖虚拟化的应用无法启动时用工具确认底层虚拟化状态是否正常。这四类场景的共同特点是问题表象五花八门但排查入口高度一致——先确认虚拟化“当前到底处于什么状态”。2. 虚拟化运行状态异常的五种典型表现别等报错才动手2.1 高频报错和背后可能的根因速查我先把过去几年出现频率最高的几类报错整理成一张表方便对照表面报错常见根因处理方向此主机支持 Intel VT-x但 VT-x 处于禁用状态固件中 VT-x 未开启进 BIOS/UEFI 开启保存重启WSL2 无法启动提示“未启用虚拟化”固件没开或 VBS/内核隔离抢占开启固件虚拟化或关闭内核隔离Docker Desktop 启动失败WSL2 后端依赖虚拟化环节被破坏检查固件开关与 Hyper-V/VBS 状态虚拟化平台安装时预检不通过固件、嵌套透传、CPU 检测逻辑冲突按检测报告逐项修软件要求调用 VT-x/AMD-V 才能继续固件关闭或系统层虚拟化被禁用优先查固件再查系统层2.2 这些症状背后的共同套路三层通道断了很多人遇到这些报错的第一反应是重装软件、重启服务这是最亏的操作。仔细观察会发现这些报错背后九成是同一个套路CPU 硬件本身早就支持虚拟化但“能把虚拟化能力交到软件手里的那条通道”没打通。通道可能断在三个位置。第一是固件层开关。这是最初级、也最容易被忽略的一道闸门。服务器在机房长期断电重启后有些固件策略会把虚拟化开关重置为关闭我遇到不止一次。第二是系统层虚拟化占用。Windows 10/11 默认开启的内核隔离、内存完整性、基于虚拟化的安全VBS以及 Hyper-V会抢占 CPU 的虚拟化扩展。此时你再运行依赖虚拟化的应用就会被告知“虚拟化不可用”哪怕 CPU 明明支持。第三是虚拟机层没有透传。如果你是在虚拟机里再跑虚拟化嵌套虚拟化而宿主机配置没有把 VT-x/AMD-V 透传进虚拟机虚拟机里看到的就是“CPU 不支持虚拟化”。注意这里不是不支持是没把开关传进来。这里有人会问手工查也能查为什么非要用工具答案是效率和一致性。手工逐层查很容易漏项。比如你只查了 /proc/cpuinfo 看到 vmx 存在就以为万事大吉却没注意到 VBS 还在占用虚拟化虚拟机照样起不来。检测工具的价值在于它固定跑同一套检测项不管是新装环境还是故障现场都能给出一份结构化的结论少漏几个环节就少走几段弯路。3. 完整排查链路从报错到定位根因的五个步骤下面这套流程是我处理虚拟化运行状态问题时固定走的路线。不管有没有工具这套思路都适用配合 dgreadiness_v3.6 的话定位速度会快很多。3.1 第一步先分清“硬件支不支持”和“硬件开没开”这一步看着简单却是很多人栽跟头的地方。判断 CPU 支不支持虚拟化看的是指令集标志位判断开没开看的是系统能不能真正调用到这些能力。这是两回事。Windows 上按CtrlShiftEsc打开任务管理器切到“性能 → CPU”右下角“虚拟化”一栏会显示“已启用/已禁用”。如果显示“已禁用”说明固件层开关没开或者系统层被占用基本不用再看别的。Linux 上更直接执行grep -E vmx|svm /proc/cpuinfo如果没有任何输出说明当前环境里根本看不到虚拟化扩展标志位要么固件没开要么是虚拟机没拿到透传。如果能看到vmx或svm说明硬件层面的能力存在问题多半出在系统调用环节。可以类比一下CPU 的虚拟化扩展就像人的两只手。看/proc/cpuinfo是确认“手存在”但手存在不等于手能用——如果被绳子绑住了固件关了、VBS 占用了照样干不了活。前面说的检测报错大多数都属于“手被绑住了”而不是“没有手”。3.2 第二步查固件设置并核对命名差异确认标志位缺失或系统提示禁用后下一步就是进固件设置。这一步最烦人的不是技术而是各家固件的命名五花八门。消费级主板上Intel 平台的选项常见叫法有 Intel Virtualization Technology、Intel VT-x、Virtualization有些主板还会把 “Intel Virtualization Technology for Directed I/O” 也放在附近那是 VT-d别和 VT-x 搞混。AMD 平台选项常见叫 SVM Mode、Secure Virtual Machine、AMD-V。如果你在 AMD 平台上满世界找 VT-x那自然是找不到的。服务器平台更“随缘”。我见过叫 Virtualization、叫 Virtualization Technology、叫 VMX、叫 SVM、叫 Advanced Virtualization 的都有。排查时别只认熟面孔看到带 “Virtualization” 的选项进去看一眼描述确认它指的是 CPU 的硬件辅助虚拟化再改。顺便提醒改完固件选项一定保存退出并做一次冷重启关机断电再开机个别平台的选项要冷启动才真正生效。只做热重启的话有些固件版本会“假装”记住了实际没加载。3.3 第三步查系统层虚拟化占用固件层确认无误、但问题依旧的时候就要查系统层了。Windows 上最常见的是 VBS基于虚拟化的安全它在 Windows 10/11 中默认开启和 Hyper-V 一样会占用虚拟化资源。查法有两种。第一种看msinfo32在“系统摘要”里找“基于虚拟化的安全”。如果显示“正在运行”或“已启用”那 VBS 就在占用虚拟化。第二种是命令行的方式reg query HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard /v EnableVirtualizationBasedSecurity在 Linux 上则要确认 KVM 内核模块是否加载、/dev/kvm是否存在且有权限lsmod | grep kvm ls -l /dev/kvm如果是麒麟这类国产系统还要注意确认加载的是kvm_intel还是kvm_amd。有些国产平台自带安全加固策略可能把/dev/kvm的权限收得很紧当前用户不属于kvm组就用不了。3.4 第四步跑 dgreadiness 并正确读报告系统层查完再用 dgreadiness_v3.6 做一次全量核对。工具跑起来很快多数环境下几分钟内出报告。报告每个检测项会给出 PASS、FAIL、WARN 三种结论重点看 FAIL其次是 WARN。我构造一个典型的检测输出来说明怎么读[DG-READINESS v3.6] System Check Report [PASS] CPU Virtualization Extension (Intel VMX) [FAIL] CPU Virtualization Enable in BIOS [WARN] Hyper-V / VBS Detected [FAIL] Nested Virtualization Available [PASS] Kernel Module (kvm_intel) Loaded这个报告反映的问题链路很清楚CPU 指令集支持PASS、固件没开FAIL、系统里有 Hyper-V 或 VBS 在占用WARN、嵌套虚拟化不可用FAIL、内核模块倒是加载了PASS。如果只看 PASS/FAIL 数量很容易忽略 WARN 那项——实际上 WARN 的 Hyper-V/VBS 很可能就是导致后面 FAIL 的元凶这类关联信息比单个检测项更有价值。3.5 第五步按场景二次验证报告看完了还要结合场景验证。物理机上跑虚拟化平台重点看固件和系统层步骤基本到此结束。但如果是在虚拟机里跑比如 VMware Workstation 里的嵌套虚拟化那还得回到宿主机设置在虚拟机的“处理器”设置里勾选“虚拟化 Intel VT-x/EPT 或 AMD-V/RVI”没勾的话虚拟机里永远看不到虚拟化能力。验证方式也简单修完哪一项就回到对应的检测命令重新查一遍。比如固件改完了回系统里再跑一次grep -E vmx|svm /proc/cpuinfo看到标志位了再继续下一步。别一次改完所有地方再统一验证那样出了问题很难定位是哪个步骤没生效。4. 修复实操四类问题的处理办法与验证手段排查的目的是修复。下面按排查链路对应的四个层级分别给出可落地的处理办法和验证方法。4.1 固件层不同平台的开启路径固件层修复说起来最枯燥但最管用。Intel 平台找 “Intel Virtualization Technology” 或 “VT-x”AMD 平台找 “SVM Mode” 或 “AMD-V”改为 Enabled保存退出。服务器平台要额外留意“启动模式”和“安全启动”的耦合。个别服务器固件在开启安全启动后默认把虚拟化相关的某些选项也锁住导致你改了 Enabled 但保存时被忽略。遇到这种情况先把安全启动临时关掉改完虚拟化设置再打开重新验证。4.2 Windows 层把 VBS/Hyper-V 的虚拟化占用让出来如果你的目标是跑 VMware、VirtualBox、Docker非 Hyper-V 模式这类依赖虚拟化的应用而系统里 VBS/Hyper-V 又占着虚拟化资源通常需要关掉后者。操作顺序建议这样先关闭内核隔离和内存完整性路径是“Windows 安全中心 → 设备安全性 → 内核隔离”把“内存完整性”关掉。然后管理员命令行执行bcdedit /set hypervisorlaunchtype off执行完重启电脑。如果 msinfo32 里“基于虚拟化的安全”已经消失虚拟化固件相关状态也正常了说明系统层占用已经让出来。注意如果你平时要跑 WSL2 或 Docker Desktop 的 WSL2 后端那边恰恰依赖 Hyper-V 平台这时候就不该把它关掉。这也是为什么我一直强调要先判断场景再动手一招通吃的方案不存在。4.3 Linux/麒麟层内核模块与设备权限Linux 下先确保模块加载modprobe kvm modprobe kvm_intel # Intel CPU # 或 modprobe kvm_amd # AMD CPU如果提示模块找不到多半是内核没编译 KVM 支持需要换内核或安装对应包Debian/Ubuntu 是 qemu-kvm 相关包CentOS/RHEL 是 kernel-modules-extra、qemu-kvm 等。然后确认/dev/kvm存在并把当前用户加进kvm组ls -l /dev/kvm sudo usermod -aG kvm $USER麒麟天逸终端虚拟化这类国产平台部署时除了基础 KVM 支持还对 CPU 型号识别、IOMMU即 VT-d/AMD-Vi状态比较敏感。部署前可以在内核启动参数里确认intel_iommuon或amd_iommuon是否已启用因为设备直通场景下 IOMMU 没开虚拟化平台的“运行状态”一样会报异常。4.4 嵌套虚拟化在虚拟机里跑虚拟化平台的正确姿势如果 dgreadiness 报告显示 CPU 指令集 PASS 但嵌套虚拟化 FAIL而你又确实是在虚拟机里跑的那就是宿主机没把虚拟化透传进来。VMware Workstation/Fusion 里在虚拟机的“处理器设置”页面勾选“虚拟化 Intel VT-x/EPT 或 AMD-V/RVI”VirtualBox 里对应的是“启用嵌套 VT-x/AMD-V”一般需要同时关掉半虚拟化接口。改完虚拟机设置必须把虚拟机关机再开机不是重启是完整的关机再启动这个配置只在冷启动时生效。启动后在虚拟机里重新跑一次检测看到 vmx/svm 标志位出现才说明透传成功。5. 实战避坑跑虚拟化检测和修复时最容易翻车的地方5.1 固件选项“文字游戏”与冷启动验证固件命名的坑值得再强调一次。有一次同事在一台国产服务器上怎么都找不到虚拟化选项因为那个固件把选项藏在 Processor Configuration → Virtualization Technology 下面而不是直接在高级菜单里。还有的固件里同时有 “Virtualization” 和 “VT-d” 两个选项前者才是 CPU 虚拟化总开关后者是 IOMMU两个都开才完整。处理这种问题的技巧是别靠关键词搜索硬找直接在固件自带的搜索功能里输入 “virtual” 或 “VMX/SVM”往往能定位到更多相关项。改完一定要冷启动验证一次不要相信热重启后的状态提示。5.2 VBS 没关干净、安全策略干扰这类隐性占用很多人关了内核隔离跑一遍 dgreadiness发现虚拟化还是 FAIL就以为工具是坏的。其实 VBS 的关闭是一个链式操作光关“内存完整性”不够要在管理员命令行里把hypervisorlaunchtype关掉然后重启。有时恢复出厂或者系统更新后这些选项会被悄悄重新打开。所以重启后要再看一次 msinfo32确认“基于虚拟化的安全”确实不在运行而不是只看“设置里关了”。在国产化环境里安全加固策略的干扰尤其明显。不少安全基线会把 hypervisorlaunchtype 或 LSM 相关策略收紧有些防护产品甚至会主动禁用/dev/kvm的可写权限。结果就是检测工具显示 CPU 支持、固件已开、内核模块已加载但虚拟化平台就是跑不起来。碰到这种情况检查一下系统审计日志里有没有 KVM 设备被拒绝访问的记录必要时把当前用户加入 kvm 组并同步确认加固策略的例外配置。5.3 报告读法、范围判断别让虚拟化背锅我见过不少同行跑完工具只看一眼“有 FAIL”然后就去重装系统。这是最可惜的操作。检测报告真正的价值在于 FAIL 项把问题定位到了具体层级——到底是 CPU 标志位缺失、固件禁用、还是内核模块没加载。每个 FAIL 对应的修复动作差得很远。学会按检测项定位五分钟就能解决的问题没必要花半天。最后提醒一句虚拟化运行状态异常不一定都是虚拟化本身的锅。有一次平台报虚拟化异常我按老套路查了固件、查了 VBS、查了内核模块全都没问题最后发现是磁盘空间满了导致相关服务起不来误报了状态。所以排查时要先把平台自己的日志和服务状态看一遍再往底层查。工具能给的是底层证据但最终判断还是要结合应用层现象。这几年我处理虚拟化运行状态问题的总结就是一句话绝大多数“虚拟化不可用”的报错都不是硬件不行而是某一层的开关没打开。固件、系统、虚拟化透传每一层都有自己独立的开关缺一个都跑不起来。dgreadiness_v3.6 这类工具的价值在于把这三层统一成一个可读的报告省去手工逐层探测的时间。但工具终究是辅助真正能让你少走弯路的还是对这条链路结构的理解。建议你下次遇到虚拟化相关报错先别急着卸载重装按固件 → 系统 → 虚拟机透传的顺序过一遍八成问题就能自己解决了。本文还有配套的精品资源点击获取