1. 误操作直通NVMe控制器一个让ESXi系统盘“消失”的经典大坑如果你正在折腾ESXi并且打算把NVMe硬盘直通给虚拟机以获得原生性能那么请务必先停下来花两分钟看完这段。我敢说这是几乎所有ESXi新手甚至一些老手都可能踩到的一个“巨坑”。这个坑的典型症状就是一通操作之后你的ESXi管理界面还能打开看起来一切正常但所有虚拟机都消失了存储设备列表空空如也任何配置更改在重启后都会“神奇”地恢复原状。更诡异的是系统明明在运行你却感觉它像失忆了一样。没错你很可能和我一样不小心把ESXi系统盘所在的整个NVMe控制器给直通了。让我还原一下我当时的情景。我的ESXi系统安装在一块NVMe固态硬盘上而我的主板恰好只有一个NVMe插槽也就是说这块系统盘和我打算直通给虚拟机的数据盘共享同一个物理NVMe控制器。在ESXi的“存储”-“PCI设备”页面里我看到了那个NVMe控制器想都没想就点了“切换直通”然后按照提示重启了主机。重启后我兴冲冲地准备把这块“直通”的NVMe分配给虚拟机时傻眼了——不仅新的直通设备没出现连原本的ESXi系统盘和数据存储都不见了。整个ESXi仿佛运行在一个失重的状态里所有需要读写硬盘的操作都失效了。这里的关键在于理解“控制器直通”和“硬盘直通”的本质区别。我们常说的RDMRaw Device Mapping直通硬盘或者像SATA控制器上某块硬盘的直通通常不会影响ESXi自身。但NVMe控制器直通是硬件级别的完全移交。当你把整个PCIe NVMe控制器直通给虚拟机时ESXi内核就会在启动后彻底放弃对这个控制器的所有权和管理权将它连同上面挂载的所有物理硬盘包括你的系统盘一并交给虚拟机。结果就是ESXi自己再也“看不见”那块装着它自己系统和配置文件的硬盘了。这就像一个船长把自己的船控制器连同驾驶舱钥匙系统盘一起送给了别人自己只能漂在救生艇内存上虽然还能发信号网络管理但再也开不动船也回不了家了。2. 为什么ESXi还能运行理解“内存中”的运行状态看到这里你可能会有一个巨大的疑问既然系统盘都访问不了了为什么ESXi还能启动Web管理界面还能打开这看起来非常反直觉。我当时也困惑了很久直到我搞明白了ESXi的启动和运行机制才恍然大悟。这恰恰是这个坑最“狡猾”的地方它没有让系统立刻崩溃而是让你陷入一个看似正常实则瘫痪的僵局。ESXi本质上是一个高度精简的、直接运行在硬件上的Linux内核。它的启动过程是这样的服务器通电后引导程序可能是UEFI或者GRUB会从你的NVMe系统盘上把ESXi的内核vmkernel和一个小型的初始化文件系统包含必要的驱动和工具加载到服务器的物理内存中。一旦加载完成ESXi内核就开始在内存里运行起来。此时它已经不再需要持续地从硬盘读取代码来维持自身的基本运作就像你把一个游戏完全载入到内存后就可以把光盘取出来一样。所以即使后续因为直通操作失去了对硬盘的访问能力这个已经在内存中跑起来的ESXi系统其核心网络栈、管理服务hostd等依然可以正常工作。这就是为什么你还能通过IP地址打开vSphere Client或Web UI甚至能用SSH登录进去。但是所有需要持久化存储的操作都失效了。比如你尝试在Web界面里取消这个直通设置点击“保存”时ESXi会尝试将这个配置写入到位于那块“消失的”系统盘上的配置文件里这个操作注定会失败。重启后由于配置无法保存直通设置依然生效ESXi再次启动加载到内存后又一次失去了硬盘陷入无限循环。我最初就试图在管理界面和SSH里用命令取消直通重启了无数次每次都徒劳无功就是因为没明白这个“内存运行存储隔离”的状态。3. 破解僵局的核心思路从外部修改“记忆”既然在ESXi内部无法修改配置因为写不回硬盘那么最直接的思路就是绕开正在运行的ESXi直接从物理层面去修改硬盘上的配置文件。这就像一个人失忆了你无法通过跟他对话来恢复记忆内部操作无效但你可以直接找到他的日记本硬盘上的配置文件修改里面的关键内容直通设置等他下次醒来重启读取日记时记忆就恢复了。ESXi的绝大部分核心配置都存储在一个名为state.tgz的压缩包文件里这个文件位于ESXi系统分区的根目录。而我们要找的关于PCI设备直通的配置就存放在state.tgz包内的/etc/vmware/esx.conf文件中。这个文件里每一行passthru配置都对应一个被直通的设备。我们的目标就是把对应NVMe控制器的那一行或者为了保险把所有直通项从passthru改为vmkernel告诉ESXi“这个设备归内核管理不要直通给虚拟机”。听起来很简单对吧我一开始也是这么想的并且走了弯路。我通过SSH登录到那个“失忆”的ESXi找到了/tardisk/state.tgz文件解压、修改、再打包结果在覆盖时发现/tardisk目录是只读的。原来ESXi在启动时会把state.tgz等几个核心压缩包解压到内存中的一个临时联合文件系统里供运行时读取。这个运行时的文件系统是允许写入的但写入的内容只存在于内存重启就丢。而原始的state.tgz文件所在的底层分区在ESXi运行时是被锁定的无法直接修改。这就彻底堵死了从内部修复的路。所以唯一的正道就是用一个外部的、独立的环境启动服务器挂载ESXi的系统分区然后修改那个“底层”的state.tgz文件。这个外部环境通常就是一个Linux Live USB启动盘比如Ubuntu、CentOS的安装U盘或救援镜像。它不依赖于服务器上的任何硬盘启动后能识别NVMe硬盘并挂载ESXi的分区这样我们就获得了完全的读写权限。4. 手把手实战用Linux Live USB修复ESXi配置理论清楚了下面就是一步步的实操环节。别怕整个过程就像给电脑重装系统一样只是我们不去装系统而是修改一个关键文件。请准备一个至少8GB的U盘。4.1 第一步制作Linux启动U盘并引导首先你需要在一台能正常上网的电脑上下载一个Linux发行版的ISO镜像。我推荐使用Ubuntu Desktop的最新LTS版本因为它对硬件驱动支持好桌面环境操作直观适合新手。你可以去Ubuntu官网下载。然后使用RufusWindows或balenaEtcher跨平台这类工具将ISO镜像写入U盘。这个过程会清空U盘所有数据请提前备份。制作完成后将U盘插入你那台“瘫痪”的ESXi服务器。开机狂按进入BIOS/UEFI设置界面的按键通常是Del、F2、F12等将启动顺序设置为优先从U盘启动保存并重启。服务器会从U盘启动进入Ubuntu的“试用Ubuntu”界面不要选择安装。等待系统加载完毕你会进入一个完整的Linux桌面环境。4.2 第二步在Linux中定位并挂载ESXi系统分区进入Ubuntu桌面后首先打开终端CtrlAltT。我们需要找到ESXi系统盘对应的分区。ESXi通常会在硬盘上创建多个分区其中存放state.tgz的分区一般是第5个分区sda5或nvme0n1p5这是一个VFAT格式的小分区。列出所有存储设备在终端输入sudo fdisk -l或sudo lsblk -f。你会看到类似下面的输出NAME FSTYPE LABEL MOUNTPOINT nvme0n1 ├─nvme0n1p1 vfat EFI ├─nvme0n1p2 ├─nvme0n1p3 ├─nvme0n1p4 └─nvme0n1p5 vfat /mnt仔细寻找类型FSTYPE为vfat且没有挂载点MOUNTPOINT的分区它很可能就是我们要找的。记下它的设备名比如/dev/nvme0n1p5。如果你的系统盘是SATA硬盘可能会显示为/dev/sda5。创建挂载点并挂载分区我们创建一个目录作为挂载点然后把分区挂载上去。sudo mkdir -p /mnt/esxi sudo mount /dev/nvme0n1p5 /mnt/esxi如果挂载成功不会有错误提示。你可以用ls -la /mnt/esxi查看一下应该能看到state.tgz、boot.cfg等文件。4.3 第三步安全备份并修改核心配置文件这是最关键的一步操作前务必做好备份。备份原始文件在修改前先复制一份原文件到安全的地方。sudo cp /mnt/esxi/state.tgz /mnt/esxi/state.tgz.backup这样万一操作失误我们还有后悔药。创建工作目录并解压我们在家目录下创建一个临时工作目录来处理这个压缩包。mkdir ~/esxi-fix cd ~/esxi-fix sudo cp /mnt/esxi/state.tgz . tar xzf state.tgz解压后你会得到一个local.tgz文件。继续解压它tar xzf local.tgz现在当前目录下会生成一个etc文件夹目标配置文件就在etc/vmware/esx.conf。修改esx.conf文件使用文本编辑器如nano打开这个文件。sudo nano etc/vmware/esx.conf在这个文件里搜索关键词passthru。你会看到类似这样的行/device/00000:00:1b.0/pciPassthru0/ids 8086:a1f0 /device/00000:00:1b.0/pciPassthru0/active true /device/00000:00:1b.0/pciPassthru0/name NVMe Controller /device/00000:00:1b.0/pciPassthru0/class class010802 /device/00000:00:1b.0/pciPassthru0/function 0 /device/00000:00:1b.0/pciPassthru0/vid 8086 /device/00000:00:1b.0/pciPassthru0/did a1f0 /device/00000:00:1b.0/pciPassthru0/rev 00 /device/00000:00:1b.0/pciPassthru0/driver passthru注意最后一行driver passthru这就是罪魁祸首。我们需要把它改成driver vmkernel。如果你不确定哪几行对应你的NVMe控制器可能有多条最保险的做法是将所有包含driver passthru的行都改为driver vmkernel。你可以手动逐行修改也可以用一条sed命令批量完成sudo sed -i s/driver passthru/driver vmkernel/g etc/vmware/esx.conf修改完成后按CtrlX输入Y保存并退出nano。4.4 第四步重新打包并替换注意致命陷阱修改完配置文件我们需要把它重新打包成state.tgz放回去。这里有一个极其重要的坑我当初就栽在这里绝对不能直接在当前目录下覆盖旧的local.tgz和state.tgz文件来创建新压缩包。你必须先删除旧的local.tgz和state.tgz文件然后从干净的etc目录开始重新打包。因为tar命令在打包时如果直接指定已存在的压缩包文件名其行为可能是“更新”而非“完全新建”这会导致压缩包内部结构错乱ESXi在启动解压时会报错Check failed: installing file ./local.tgz (sandbox is local.tgz)而无法启动。正确的打包命令序列如下# 1. 删除旧的压缩包 rm -f local.tgz state.tgz # 2. 将修改后的etc目录打包成新的local.tgz sudo tar czf local.tgz etc/ # 3. 为local.tgz设置正确的权限755 sudo chmod 755 local.tgz # 4. 将local.tgz打包成最终的state.tgz sudo tar czf state.tgz local.tgz # 5. 为state.tgz设置正确的权限755 sudo chmod 755 state.tgz现在用我们新生成的、正确的state.tgz文件覆盖掉ESXi系统分区上的原文件sudo cp -f ./state.tgz /mnt/esxi/4.5 第五步卸载分区并重启确保文件复制无误后卸载分区然后重启服务器。sudo umount /mnt/esxi sudo reboot重启时记得拔掉Linux U盘或者进入BIOS将启动顺序改回从你的NVMe硬盘启动。如果一切顺利你会看到ESXi正常启动并且不再丢失存储设备。登录管理界面检查“存储”和“PCI设备”页面你的系统盘应该回来了NVMe控制器的直通状态也应该被解除了。5. 防患于未然如何安全地进行NVMe直通经历了这次惊心动魄的修复我们更应该思考如何避免踩坑。对于NVMe设备的直通我总结了几个安全准则。首要原则系统盘与数据盘物理隔离。这是最根本的解决方案。如果你的主板有多个M.2插槽或PCIe插槽并且它们由不同的控制器管理例如一个来自CPU直连一个来自芯片组那么请务必将ESXi系统安装在与众不同的那个控制器上的硬盘。比如系统装在由芯片组管理的SATA SSD或一个NVMe上而将CPU直连的、性能更好的那个NVMe控制器整个直通给虚拟机。这样无论你怎么折腾直通都不会影响到系统盘。如果只有一个控制器务必采用RDM方式。当你的系统盘和数据盘不得不共享同一个NVMe控制器时绝对不要直通整个控制器。应该使用RDM原始设备映射的方式将数据盘以“裸盘”的形式映射给虚拟机。在ESXi的存储视图中找到你的数据盘右键选择“数据存储浏览器”上传文件的功能虽然不适用但你可以通过SSH命令行使用vmkfstools命令来创建RDM映射文件。这样ESXi内核仍然保有对控制器的管理权只是将特定物理盘的访问权“穿透”给了虚拟机。虽然性能比完全直通控制器略有一丁点开销但换来了系统的绝对安全。操作前熟读官方文档并备份配置。VMware的官方文档明确说明了直通控制器的风险。在进行任何直通操作前尤其是存储控制器一定要确认目标设备上没有ESXi的引导分区或核心存储。此外养成定期备份ESXi主机配置的习惯。在ESXi的Web Client里进入“主机”-“操作”-“设置”-“系统”-“备份配置”可以轻松生成一个配置文件备份。万一出了问题至少可以通过恢复配置来快速还原大部分设置。修改关键配置前先做快照或克隆。如果你是在虚拟机里做类似的危险实验快照是救命稻草。虽然ESXi主机本身不支持快照但你可以通过上述备份配置的方式或者使用像VMware vCenter Server这样的集中管理工具它提供了主机配置配置文件的管理功能。对于家庭或实验室环境至少确保你有最近可用的ESXi安装镜像和你的许可证密钥以便在最坏情况下能重装恢复。6. 进阶思考ESXi存储架构与故障排查启示这次修复经历不仅仅是一个操作教程更是一次对ESXi底层架构的深刻理解。ESXi这种将运行时环境与配置存储分离的设计内存中运行配置存于持久存储既是其高可靠性和高性能的基石也带来了此类独特的故障模式。它提醒我们在管理任何类似的基础设施时都要明确区分“运行时状态”和“持久化配置”。当系统行为异常如配置不保存、设备消失但核心服务却正常时就应该立刻怀疑是否是持久化存储层出现了问题。排查思路可以沿着这条线展开首先确认存储设备是否被系统识别lsblk,esxcli storage core device list其次检查配置文件所在的分区是否正常挂载且可写df -h, 尝试创建测试文件最后再深入到配置文件的语法和内容是否正确。对于更复杂的存储问题ESXi提供的esxcli命令套件是强大的排错工具。例如esxcli storage filesystem list可以列出所有已挂载的文件系统及其属性vmkload_mod -l可以查看已加载的驱动模块确认NVMe驱动是否正常。养成通过SSH使用命令行工具深入检查的习惯远比单纯依赖Web界面点击更能发现问题根源。最后这次事件也体现了“外部救援环境”在系统维护中的不可替代性。一个随手可得的Linux Live USB不仅仅是安装系统的工具更是系统修复的“瑞士军刀”。无论是Windows的PE还是Linux的Live CD在服务器运维的工具箱里都应该常备一份。当系统自身无法引导或运行时它们能提供一个干净、可控的外部操作环境直接对“患病”的硬盘进行手术这往往是解决棘手问题的最后也是唯一的手段。