ESXi 8.0安装引导过程停留在loading module svm界面不再往下执行，该故障绝大多数发生在AMD CPU硬件平台。svm模块对应AMD‑V硬件虚拟化驱动，BIOS中虚拟化相关开关配置冲突、嵌套页表NPT、AMD‑Vi(IOMMU)开启异常，或者物理机之前安装过Windows Hyper‑V未彻底关闭，都会造成svm内核模块初始化挂死，无法进入ESXi安装向导。需要针对性调整BIOS选项，必要时增加内核启动参数绕过冲突。
一、机房现场故障踩坑背景
一台AMD EPYC服务器，使用官方ESXi8.0 U2 ISO引导安装，开机加载模块阶段固定卡在loading module svm，屏幕无报错、无重启，长时间无响应。运维反复重新制作安装U盘、更换光驱介质、重置BIOS为默认，故障依旧复现。 1.1 初期无效排查操作
更换不同版本ESXi8.0小版本；关闭Secure Boot；切换CSM兼容模式；更换U盘、换不同接口；没有针对性调整AMD虚拟化与IOMMU相关BIOS选项，故障不能解除。
1.2 分层定位真实故障根因
BIOS中SVM Mode已经开启，但同时开启AMD‑Vi(IOMMU)，嵌套页表NPT固件存在兼容性bug，svm模块初始化和IOMMU发生资源冲突导致内核挂死；部分台式锐龙主板，Windows Hyper‑V关闭后固件虚拟化状态未完全复位，同样引发svm模块卡死。 现场验证修复：BIOS临时关闭AMD‑Vi(IOMMU)，保留SVM Mode开启，关闭嵌套页表相关自动选项，保存重启，正常进入ESXi安装界面，安装完成后再按需开启IOMMU。
二、loading module svm卡死底层原理
1、SVM模块作用
svm是ESXi内核中AMD‑V硬件虚拟化驱动模块，主机上电引导时，svm模块会读取CPU、BIOS虚拟化寄存器，完成AMD‑V硬件虚拟化初始化，是ESXi hypervisor运行的前置依赖模块。该模块加载失败直接终止整个安装引导流程。
2、主要冲突来源
AMD‑Vi(IOMMU)开启状态下，部分主板固件存在寄存器交互bug，svm初始化与IOMMU抢占硬件资源，直接死锁挂起；Windows系统开启Hyper‑V之后即便卸载Hyper‑V，部分主板固件虚拟化状态不会复位，残留的虚拟化状态干扰ESXi svm模块识别；部分锐龙消费级主板，嵌套分页NPT自动模式固件实现缺陷，触发svm模块挂死。
3、区分硬件不支持和固件冲突
CPU硬件完全不支持SVM虚拟化，一般直接抛出报错提示；而卡在loading module svm多数属于硬件支持，但BIOS固件配置冲突导致模块初始化死锁，并非CPU不支持虚拟化。
4、Secure Boot影响
Secure Boot本身不会直接造成svm卡死，但部分主板开启Secure Boot会改变虚拟化寄存器行为，间接放大IOMMU与SVM的兼容性问题。
三、标准化排查判断标准与BIOS配置步骤
1、必改BIOS选项（AMD平台）
SVM Mode(AMD‑V)：设置为Enabled，ESXi必须开启该选项，不可关闭； AMD‑Vi / IOMMU：安装ESXi阶段临时设置为Disabled，安装完成系统正常启动后再开启用于SR‑IOV设备透传； Nested Paging(NPT嵌套页表)：修改为Disabled或者Force关闭，不要使用Auto自动模式； 关闭主板层面嵌套虚拟化开关，部分消费级主板存在独立Nested Virtualization选项。
2、曾经安装Windows Hyper‑V的物理主机
进入Windows系统彻底关闭Hyper‑V、虚拟机平台、Windows沙箱功能，执行bcdedit /set hypervisorlaunchtype off，完全关机断电，冷重启服务器，清除固件残留虚拟化状态，再引导ESXi安装镜像。热重启无法清除部分固件寄存器状态。
3、ESXi启动参数调试手段
在ESXi安装引导菜单按Shift+O编辑启动选项，在内核行末尾追加noIOMMU参数，回车启动安装介质，用于绕开IOMMU冲突，适合服务器BIOS选项较少无法关闭AMD‑Vi的硬件。
4、固件版本建议
消费级锐龙主板优先升级到主板厂商最新BIOS版本；服务器EPYC主机升级iDRAC/ILO固件，修复虚拟化相关固件bug。
四、高频故障排错清单
| 故障现象 | 根因分析 | 标准解决方案 |
|---|---|---|
| 引导固定卡在loading module svm，无报错，AMD平台 | BIOS AMD‑Vi(IOMMU)开启，与SVM模块初始化发生固件冲突死锁 | BIOS关闭AMD‑Vi(IOMMU)，SVM Mode保持Enabled；BIOS没有开关则启动增加noIOMMU内核参数 |
| 关闭IOMMU依旧卡在svm模块 | NPT嵌套页表Auto模式固件存在兼容性缺陷 | BIOS手动关闭Nested Paging嵌套页表，不使用Auto自动模式 |
| 主机之前跑过Windows Hyper‑V，切换安装ESXi就卡死svm | Hyper‑V关闭后固件虚拟化寄存器状态没有复位，热重启无法清除状态 | Windows内关闭Hyper‑V相关组件，执行bcdedit关闭hypervisor，整机断电冷启动再引导ESXi |
| 服务器BIOS选项有限，找不到IOMMU、NPT开关 | OEM服务器BIOS屏蔽部分高级CPU配置选项 | ESXi安装引导按Shift+O，追加noIOMMU内核参数完成安装，系统部署完成后再做调优 |
| 关闭IOMMU可以安装成功，重启进ESXi系统再次卡在svm | 主板BIOS保存配置异常，保存后IOMMU、NPT配置未真正生效 | 确认BIOS修改后F10保存退出，断电冷开机，不要使用热重启；升级主板固件版本 |
五、运维高频误区避坑
1.误区：卡在svm模块，直接BIOS把SVM Mode关闭纠正：SVM Mode必须Enabled，ESXi hypervisor依赖AMD‑V虚拟化；卡死不是SVM没开，是IOMMU/NPT和SVM冲突。
2.误区：热重启修改完BIOS直接测试，不需要断电纠正：AMD平台部分寄存器状态只有整机断电冷重启才会重置，热重启配置不会完全生效。
3.误区：安装成功之后也必须永久关闭IOMMU纠正：安装阶段关闭仅为规避安装引导冲突；系统安装完成稳定运行后，可以重新开启AMD‑Vi(IOMMU)，用于SR‑IOV设备透传。
4.误区：更换ESXi小版本更新包就能解决svm卡死纠正：该故障绝大多数属于BIOS固件层面冲突，不是ESXi版本bug，换版本无法根治问题。
5.误区：Secure Boot是svm模块卡死的直接原因纠正：Secure Boot一般引发模块签名报错，不会表现为svm模块静默挂死；可临时关闭辅助排查，但不是根因。
六、AMD平台ESXi8.0部署标准化运维规范
部署前规范：AMD平台部署ESXi8.0，安装引导阶段，优先临时关闭AMD‑Vi(IOMMU)，NPT嵌套页表避免Auto模式，完成安装再按需恢复IOMMU功能。
介质规范：使用VMware官方ISO镜像，校验SHA256，规避镜像损坏带来模块加载异常。
Windows迁移规范：物理机从Windows Hyper‑V环境改为ESXi，必须关闭全部Windows虚拟化组件，整机断电冷启动，再引导ESXi安装。
调试规范：BIOS没有对应开关时，使用Shift+O增加noIOMMU启动参数作为应急安装手段。
固件规范：锐龙、EPYC服务器部署ESXi前，优先升级主板、BMC到官方最新固件，规避虚拟化相关固件缺陷。