文章总结： 本文解决联想R9000P运行VMware报错不支持AMD-V的问题，指出系Windows基于虚拟化的安全独占CPU资源所致。常规关闭Hyper-V无效后，作者提供了修改注册表强制禁用DeviceGuard和内核隔离的解决方案，成功释放硬件资源以恢复虚拟机加速性能，并分析了VBS原理及性能权衡。
综合评分： 88
文章分类： 实战经验,安全工具,办公安全
虚拟机-此平台不支持虚拟化的 AMD-V/RVI
原创
hack07
网络攻防研究
2026年1月12日 17:02
上海
前言：博主刚买台联想拯救者-R9000P。心情愉悦的装上虚拟机，准备大展手脚，结果提示了：此平台不支持虚拟化的 AMD-V/RVI
点击”是“后：
博主此时心里有一万批马奔腾，而过。。。。。
然后博主开始解决：
首先博主直接打开虚拟机，然后点击编辑虚拟机设置
点击处理器，可以看到有个“虚拟化 Intel VT-x/EPT” 或AMD-V/RVI(V),把它去掉可以看到虚拟机此时就可以正常运行了！
？？？why？？？估计此时小伙伴和博主一样，心中充满了疑惑：
这个选项的核心是 “虚拟机是否调用主机 CPU 的硬件虚拟化功能”，取消勾选能解决问题的原因是：
该选项勾选时，虚拟机需要依赖主机已开启的硬件虚拟化（如 AMD-V）来运行；而当前问题的根源是 “硬件虚拟化相关功能（含嵌套虚拟化）存在冲突 / 未正确适配”，导致 HV 模块（硬件虚拟化对应的虚拟机模块）启动失败。
若取消勾选，虚拟机就会切换为 “软件模拟虚拟化” 模式 —— 不再依赖主机的硬件虚拟化功能，自然也就避开了 HV 模块的启动异常，因此能启动虚拟机。
但代价是：软件模拟的性能远低于硬件加速，虚拟机运行会更卡顿（尤其是高负载场景）。
也就是说，此时我们不能硬件加速了！！！对于咱们R9-8945HX的高配置用户来说，这行吗？当然不行！
于是博主，就win+r输入control,点击程序->启用或关闭windows功能
取消勾选以下两个选项，重启。此时我们打开虚拟机，发现一样的错误。
说明：这里主要排除Windows 的虚拟化冲突
这个冲突的核心原因是：CPU 的虚拟化扩展（你电脑里的 AMD-V/SVM）是 “独占资源”—— 同一时间只能被一个软件 / 系统组件占用，而 Hyper-V、内存完整性都是依赖这个硬件虚拟化功能运行的，会和 VMware 抢资源。
具体来说：
- Hyper-V 的占用：Hyper-V 是 Windows 自带的虚拟化平台，它启动后会直接 “接管” CPU 的 AMD-V/SVM 功能。此时 VMware 再想调用 AMD-V，就会因为资源被 Hyper-V 占着而无法使用，导致冲突。
- 内存完整性的间接依赖：“内存完整性”（内核隔离）是基于 Hyper-V 的虚拟化技术实现的 —— 哪怕你没手动开启 Hyper-V，开了内存完整性也等于 “后台启用了 Hyper-V 的核心组件”，同样会占用 AMD-V 资源，间接和 VMware 抢硬件虚拟化权限。
因此我们下一步关闭内存完整性：直接win+i，找到隐私和安全性->Windows安全中心->设备安全性->内核隔离详细信息，关闭即可
然后我们重启，发现还是一样的问题，于是博主检查了一下bios设置，发现也已经启用虚拟化。
于是，博主win+r输入sminfo32,看了一下系统信息，发现”基于虚拟化的安全性”仍然处于正在运行中。
于是博主管理员终端输入下面命令重启，发现还是一样的报错：
bcdedit /set hypervisorlaunchtype off
博主输入sminfo32查看，依然在运行中，于是：
注册表强制禁用（谨慎操作，先备份注册表）
- Win+R → regedit，定位：
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard
-
新建 / 修改 DWORD：
EnableVirtualizationBasedSecurity= 0 -
再定位：
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity
- 新建 / 修改 DWORD：
Enabled= 0 - 重启后再次检查内存完整性开关。
此时博主重启后，发现已经完美解决上述问题。
当然也可以用微软官方工具 DG_Readiness 彻底禁用（管理员 PowerShell）
# 下载解压后执行.\DG_Readiness_Tool_v3.6.ps1 -Disable
完成后重启。
Win+R → msinfo32，查看基于虚拟化的安全性，状态应为未启用。
提示：关闭 VBS 会降低系统安全防护，仅在性能需求明确时执行；若后续需要运行 WSL2、虚拟机等，可通过
bcdedit /set hypervisorlaunchtype auto重新启用。
那这个基于虚拟化的安全性是做什么用的？
基于虚拟化的安全性（VBS，Virtualization-based Security） 是微软 Windows 系统中一套依托硬件虚拟化技术构建的深层安全防护体系，核心是通过Hyper-V 虚拟机监控器创建一个与常规系统内核隔离的、高度特权的安全执行环境（Secure Kernel/Isolation Container），以此抵御传统安全机制难以应对的内核级恶意攻击。
其中内存完整性（HVCI，Hypervisor-Enforced Code Integrity） 是 VBS 最核心、最常用的配套功能，二者常被一并提及和配置。
一、核心工作原理
- 硬件基础：必须启用 CPU 虚拟化（Intel VT-x/AMD-V）、二级地址转换（SLAT），并配合 TPM 2.0 + 安全启动（Secure Boot）实现完整防护；
- 隔离机制：安全内核运行在比 Windows 常规内核更高的特权级别（Ring -1），常规内核与用户态代码无法直接篡改或访问安全区域的数据；
- 执行逻辑：VBS 将敏感安全任务和数据迁移到隔离区域，同时通过 HVCI 强制验证所有加载到内核模式的代码（驱动、模块等），拒绝未签名 / 恶意代码执行。
二、核心安全功能与防护场景
| 功能模块 | 核心作用 | 防护场景 |
| — | — | — |
| 内存完整性（HVCI） | 强制内核代码签名验证，阻止恶意驱动 / 内核模块注入 | 勒索软件内核级注入、rootkit、恶意驱动攻击 |
| 凭据保护（Credential Guard） | 隔离存储 NTLM 哈希、Kerberos 票据等敏感凭据 | Pass-the-Hash（哈希传递）、票据窃取攻击 |
| 设备防护（Device Guard） | 限制仅可信代码运行，构建白名单执行环境 | 零日恶意软件、未授权代码执行 |
| 内核数据保护（KDP） | 隔离内核敏感数据结构，防止篡改 | 内核漏洞利用、权限提升攻击 |
| 虚拟安全模式（VSM） | 为其他安全组件（如 Windows Hello）提供隔离执行环境 | 生物识别数据窃取、身份冒充 |
三、适用与代价
- 适用场景：企业终端、金融设备、政务系统等对安全要求极高的环境，尤其适合防御高级持续性威胁（APT）和内核级恶意软件；
- 性能代价：启用 VBS/HVCI 会占用少量额外内存和 CPU 资源，可能导致部分老旧驱动不兼容（驱动必须支持 HVCI 签名），对游戏、虚拟机等性能敏感场景有轻微影响；
- 启用前提：Windows 10 1607+（专业 / 企业 / 教育版）、支持虚拟化的 CPU、TPM 2.0、安全启动开启。
四、补充说明
- VBS 本身是安全框架，HVCI 是其最核心的执行层功能，二者常被一起启用 / 禁用；
- 关闭 VBS 会直接影响上述所有防护功能，降低系统安全等级，仅建议在驱动不兼容或性能需求明确时执行；
- 若需运行 WSL2、Hyper-V 虚拟机等，可单独启用 hypervisor（
bcdedit /set hypervisorlaunchtype auto），不一定需要开启 VBS/HVCI。
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：网络攻防研究 hack07《虚拟机-此平台不支持虚拟化的 AMD-V/RVI》