企业官网建设流程全解析

简介：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 处于禁用状态。你回头打开任务管理器，性能页上“虚拟化”那一行写着“已禁用”。明明是支持虚拟化的 CPU，BIOS 里也没印象动过什么，重启三次得到的还是同一句提示。这类故障卡住的不是一个小功能，而是整条工作流——本地调试环境、镜像构建、多系统并存的测试，全都得排队等它。折腾过的人都知道，虚拟化报错难受的地方不在解决难度，而在信息量太少：一句“不支持”，背后可能是固件开关没打开、可能是系统里另一个 hypervisor 先把 VT-x 占了、也可能真的是主板或平台锁死。把这三层拆开看，事情才有解。

2. 固件层的红灯：任务管理器显示“已禁用”，BIOS 里却明明是开的

固件层是排查顺序里的第一站，也是被误判最多的一站。很多人一看任务管理器写着“已禁用”，立刻重启进 BIOS，把 Virtualization Technology 打开，保存退出，回来一看——还是禁用。于是开始怀疑主板坏了、CPU 不支持。实际上一台机器上“虚拟化”这个词至少对应三样东西：CPU 的硬件虚拟化扩展（Intel 叫 VT-x，AMD 叫 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

三个布尔值的组合基本能把情况定死，不用再猜：

VMMonitorModeExtensions读的是 CPUID 里的能力位，是硬件事实，改不了；VirtualizationFirmwareEnabled读的是固件把控制权交没交给 OS，取决于 BIOS/UEFI 设置；HypervisorPresent表示当前已经有一层 hypervisor 在跑，这时候第三方虚拟化软件通常拿不到根权限。这三者的区别一定要分清，很多人把第二项当成第一项，白白换了一轮内存条。

Linux 侧对应的检查更直接，一行 grep 就够：

# 统计 CPU 暴露的虚拟化扩展数量，结果为 0 说明固件没开或 CPU 不支持 grep -c -E '(vmx|svm)' /proc/cpuinfo # 更可读的方式，看 Virtualization 一行 lscpu | grep -i virtualization

vmx是 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 Mode：CPU 硬件虚拟化，装 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, SecurityServicesConfigured

SecurityServicesRunning里如果出现 1（Credential Guard）或 2（HVCI，即内存完整性），基本可以确定是它占着。对应的开关在两个地方：

# 查内存完整性是否开启，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-DisposableClientVM（Windows 沙盒）。只要其中任意一项是 Enabled，VT-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、关 VBS，折腾两小时毫无进展。判断办法很简单：报告里如果明确标出当前系统运行在虚拟化平台上，而目标又是再跑一层虚拟机，那这就是嵌套虚拟化的问题，本地配置怎么改都没用。

注意：检测报告是快照，不是实时监控。改完配置必须重新跑一次，用新报告确认红灯变绿，而不是凭感觉认为“应该好了”。我见过太多“我改过了”——改的可能是另一个启动项，或者根本没重启。

4.3 让检测结果可复现：把报告存下来做基线

单次检测只能回答“现在是什么状态”。真正省时间的是留基线：机器刚装好、一切正常的时候跑一次，把输出存成文件；以后出问题，跑一次新的，两份对着看差异，根因往往就藏在那一两行的变化里。

# 以管理员权限运行，把报告重定向到文件，方便和基线对比 dgreadiness.exe > readiness-baseline.txt 2>&1 # 出问题时再跑一次 dgreadiness.exe > readiness-now.txt 2>&1 # 对比两份报告，只看差异行 diff -u readiness-baseline.txt readiness-now.txt

> file 2>&1把标准输出和错误输出一起重定向，避免关键报错落在控制台没被记下来。文件名带上日期更好，比如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 的机器上，这一项默认是 Enabled，VT-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 可选功能。三处查完基本能锁定来源。这里有个提速技巧：不要一个个开关试，直接用检测工具一次性抓齐，再对着报告里的红灯项处理。

第三步，问“环境允不允许”。如果前两步都正常还起不来，或者报告明确标出当前运行在虚拟化平台上，那就别再折腾本地配置了，去确认嵌套虚拟化支持情况。

把这三步压成一张对照表，贴在排查笔记里最省事：

验证环节同样要有固定动作，不能靠“感觉好了”。改完配置后按这个顺序复核：先跑检测拿新报告，确认红灯项转绿；再启动一次目标虚拟化软件，走到能创建并启动客户机为止；最后看一眼事件查看器里有没有虚拟化相关的错误记录残留。三步都过，才算真的修好。只做第一步很容易出现“报告绿了但实际跑不起来”的假修复，尤其是 5.5 那种残留驱动的情况。

还有个小习惯值得养成：每次动配置之前，先把当前状态存一份。改坏了能回退，改好了有对比，改到一半被人打断回来也知道自己走到哪儿了。这份基线文件在多人协作时更好用——别人报故障，你让他发报告而不是描述现象，描述永远丢细节。

从那以后我每台新机器到手，第一件事就是跑一遍检测把报告存成基线文件，配置变更前再存一份。踩过的坑告诉我，虚拟化这块的报错文案可信度很低，真正可信的只有命令返回的那几个布尔值。希望帮到你。

本文还有配套的精品资源，点击获取