1. 项目概述一次典型的ESXi补丁安装故障排查在虚拟化运维的日常里给ESXi主机打补丁、安装驱动或者VIBvSphere Installation Bundle文件本应是像给汽车做保养一样常规的操作。但偏偏就是这种“常规操作”最容易冷不丁地给你抛出一个让人心头一紧的错误。最近在给一批ESXi 7.0主机更新一个关键驱动时我就遇到了这个经典的拦路虎“The pending transaction requires xxx MB free space“ error when installing VIBs。屏幕上这行冷冰冰的提示意味着安装事务因为空间不足而被硬生生地卡住了。这可不是简单的“磁盘满了”那么简单它背后牵扯到ESXi独特的临时文件系统、事务处理机制以及一个常被忽略的/scratch分区。如果你也正在为这个错误抓耳挠腮或者想提前了解如何规避那么这次从踩坑到填坑的完整经历或许能给你提供一个清晰的排查路线图。这个错误的核心直指ESXi系统中的一个关键设计任何软件变更安装、升级、卸载VIB都不是直接进行的而是被视为一个“待处理事务”。系统会为这个事务预留出足够的临时空间用于暂存文件、处理依赖和回滚操作。当它提示需要xxx MB空间时就是在告诉你为这个事务准备的“工作台”不够大了。而这个“工作台”主要就是/scratch分区以及相关的临时目录。处理这个问题远不止是“删点东西”那么简单它需要你理解ESXi的存储布局、事务处理逻辑并掌握一套行之有效的空间清理与配置方法。2. 错误深度解析不只是“磁盘已满”乍一看“requires xxx MB free space”就是个空间不足的错误。但在ESXi的世界里空间有很多种用错了地方就是白费功夫。首先我们必须摒弃在通用Linux服务器上的思维定式。ESXi采用了一个高度定制化、内存引导的轻量级系统它的存储结构非常独特。2.1 ESXi存储架构与关键分区一台ESXi主机的存储通常由几个核心分区组成每个都有其神圣不可侵犯的职责Bootbank/Altbootbank这是系统引导分区采用只读设计。你当前运行的系统文件就在这里另一个分区则用于系统更新后的回滚。你几乎无法也绝不应该直接在这里腾出空间。/scratch分区这是本次错误的“主角”。它是一个独立的、用于存储临时文件、日志、核心转储和软件事务临时数据的专用分区。默认情况下如果ESXi检测到一个有标签的本地磁盘或USB/SD卡它会自动在此创建一个/scratch分区。如果没有它会退而求其次使用/tmp/scratch一个位于内存文件系统tmpfs中的链接但这非常不可靠因为内存空间有限且重启后数据会丢失。/tmp和/var/log这些目录通常链接到/scratch分区下的子目录如/scratch/tmp,/scratch/log。如果/scratch分区配置不当或空间不足这些关键的系统运行和日志记录功能也会受到影响。当执行esxcli software vib install这类命令时系统会启动一个事务。这个事务需要安全的空间来暂存下载或解压VIB包文件。预处理验证签名、检查依赖关系、计算文件系统变更。回滚准备为可能的安装失败准备恢复点。 所有这些操作所需的临时空间主要就依赖于/scratch分区。因此错误信息中的xxx MB就是事务管理器计算出的、在/scratch或相关临时区域必须满足的最小空闲空间。2.2 事务处理机制与空间预留ESXi的软件生命周期管理非常严谨。它不允许直接对运行中的系统进行“热修改”。任何VIB操作都是一个多阶段事务创建待处理事务系统评估操作影响并在/scratch等位置预留空间生成事务元数据。暂存文件将VIB包及相关文件解压到临时区域。验证与预执行在隔离环境中模拟安装检查冲突。提交或回滚如果一切就绪在下次重启时提交更改如果失败则利用预留的信息回滚。这个机制的优点是安全确保了系统一致性。但缺点也很明显它对临时空间有硬性要求。如果预留失败整个事务就会被拒绝并抛出我们看到的这个错误。这解释了为什么主机看起来还有不少剩余存储但安装却失败——因为可用空间不在正确的位置上。3. 系统性排查与诊断流程遇到这个错误不要急于盲目删除文件。一个系统性的诊断能帮你快速定位病根。请通过SSH或ESXi Shell连接到你的主机按以下顺序进行检查。3.1 第一步确认/scratch分区的配置与状态这是最关键的一步。首先查看/scratch当前指向哪里以及它的空间使用情况。df -h | grep -E ‘(scratch|Filesystem)’或者使用更专门的命令esxcli system syslog config get | grep “Scratch”理想情况下你应该看到/scratch挂载在一个独立的、有足够空间的分区上例如/dev/disks/xxxx:5。如果输出显示/scratch - /tmp/scratch或类似指向tmpfs的链接那么问题很可能就出在这里——内存中的临时空间根本不足以处理VIB事务。接下来检查该分区的详细使用情况df -h /scratch记下Use%一栏。如果使用率超过85%甚至在95%以上那么空间紧张就是安装失败的直接原因。3.2 第二步分析/scratch分区的内容构成知道空间不足后我们需要知道是什么占用了空间。进入/scratch目录进行分析cd /scratch du -sh * | sort -hr | head -20这条命令会列出/scratch下各个子目录和文件的大小并按从大到小排序显示前20个。常见的“空间大户”包括log目录系统日志文件特别是如果日志级别设置过高或长期未清理可能会积累数GB的日志。core或dumppart目录系统崩溃时生成的核心转储文件单个文件就可能非常大。updates或tmp目录存放临时下载的更新包或事务残留文件。残留的VIB事务目录形如esx-xxxxx的临时目录可能是之前失败或中断的事务留下的。仔细查看这个列表你就能找到主要的空间消耗者。3.3 第三步检查主机整体存储与内存状况虽然问题焦点在/scratch但了解主机整体状况有助于排除其他干扰。检查引导设备通常是/根目录的空间df -h /同样检查内存使用情况因为如果/scratch链接到tmpfs内存不足也会导致问题free -m如果根分区也接近满载可能会影响系统整体稳定性但VIB安装错误通常更直接关联/scratch。4. 实操解决方案清理、重配与安装诊断完成后我们就可以针对性地解决问题了。解决方案遵循一个清晰的升级路径从最简单的清理到重新配置最后完成安装。4.1 方案一安全清理/scratch分区这是最直接的方法。在删除任何文件前请务必确认其不再需要。对于日志文件可以先进行归档或备份。清理旧日志ESXi会自动轮换日志但你可以手动清理过旧的日志。一个相对安全的方法是使用logrotate功能或直接删除特定日期的日志文件。例如可以删除一段时间前的vmkernel.log旧文件find /scratch/log -name “vmkernel.*.gz” -mtime 30 -exec rm {} \;注意/scratch/log通常链接到/var/log。直接操作/scratch/log即可。建议先使用ls -la确认目录链接关系。删除核心转储文件核心转储对于调试致命错误至关重要但如果问题已解决旧的转储文件可以删除。rm -f /scratch/core/*或者如果核心转储配置在专用分区esxcli system coredump partition list esxcli system coredump partition set –enable false # 清理后可以重新启用 esxcli system coredump partition set –partition 分区名 –enable true清理临时事务目录查找并删除残留的VIB安装临时目录。ls -la /scratch/ | grep esx- # 确认目录是旧的、无用的之后 rm -rf /scratch/esx-xxxxx清空临时文件夹rm -rf /scratch/tmp/*完成清理后再次运行df -h /scratch确认可用空间已显著增加并且远大于错误提示中要求的xxx MB。4.2 方案二重新配置/scratch分区到持久化存储如果发现/scratch链接到了/tmp/scratch内存中那么无论你怎么清理重启后配置都会丢失且空间永远受限。这是生产环境中必须修正的配置。你需要将/scratch指向一个本地磁盘、USB或网络存储如VMFS数据存储上的持久化目录。识别可用存储首先列出所有可用的数据存储。esxcli storage filesystem list找一个有足够空间建议至少5-10GB的数据存储记下它的挂载点例如/vmfs/volumes/datastore1。创建并配置/scratch目录# 在选定的数据存储上创建scratch目录 mkdir -p /vmfs/volumes/datastore1/scratch # 将系统的scratch配置指向新位置 esxcli system syslog config set –logdir/vmfs/volumes/datastore1/scratch/log esxcli system syslog reload # 配置核心转储路径可选但建议 esxcli system coredump file set –file /vmfs/volumes/datastore1/scratch/core # 最后设置主scratch分区 esxcli system syslog config set –scratchdir/vmfs/volumes/datastore1/scratch esxcli system syslog reload验证配置执行以下命令确认/scratch现在指向新的持久化路径。esxcli system syslog config get ls -la /scratch df -h /scratch重启主机后此配置应保持不变。现在/scratch就有了稳定且充足的空间。4.3 方案三执行VIB安装并验证在确保/scratch分区有充足空间例如可用空间是所需空间的2倍以上后重新运行之前失败的安装命令。例如esxcli software vib install -v “/path/to/your/package.vib” –no-sig-check # 或者从在线仓库安装 esxcli software vib install -n vibname提示–no-sig-check参数仅在确认VIB来源可信且签名检查失败时使用。在生产环境中应优先解决签名验证问题。安装过程中可以通过另一个SSH会话监控/scratch空间的使用变化watch -n 2 ‘df -h /scratch’你会看到空间被临时占用安装完成后又会释放。安装成功完成后务必重启主机以使VIB生效这是ESXi软件变更的标准流程。reboot重启后使用以下命令验证VIB是否已正确安装esxcli software vib list | grep -i “vibname”5. 深度优化与长效预防策略解决一次问题固然好但建立预防机制才能高枕无忧。针对这个错误我们可以从配置、监控和维护三个层面建立防线。5.1 配置最佳实践在安装阶段规划/scratch在部署ESXi主机时无论是通过Auto Deploy还是镜像安装都应明确指定一个持久化存储作为/scratch分区。避免依赖默认的tmpfs配置。分配充足空间为/scratch分区分配合理的空间。对于一般用途的主机10-20GB是一个安全的起点。如果主机需要频繁安装大型驱动或补丁或者日志量非常大应考虑分配更多空间。使用专用磁盘如果条件允许使用一块小容量的SSD或USB驱动器专门用于/scratch和日志。这可以避免与虚拟机数据存储I/O产生竞争同时也能提供更好的性能。5.2 监控与告警设置不能等到安装失败才发现空间不足。应将/scratch分区的空间使用率纳入日常监控。vCenter Server告警在vCenter中可以为每台主机的/scratch目录空间创建性能图表并设置告警。当使用率超过80%时触发警告超过90%时触发严重告警。通过ESXCLI脚本监控可以编写一个简单的PowerShell或Python脚本定期通过SSH执行df -h /scratch命令解析输出并通过邮件或监控平台API发送告警。# 示例简单的检查脚本片段 usage$(df -h /scratch | awk ‘NR2 {print $5}’ | cut -d’%’ -f1) if [ $usage -gt 80 ]; then echo “警告/scratch 分区使用率 ${usage}%” | mail -s “ESXi空间告警” adminexample.com fi5.3 自动化维护任务通过计划任务定期自动清理可以极大降低空间不足的风险。配置日志轮转确保ESXi的日志轮转配置合理。可以编辑/etc/logrotate.conf文件在ESXi中位置可能不同或通过高级设置配置调整日志文件的保留数量和大小。创建定期清理脚本将前面提到的清理命令整合到一个脚本中并利用ESXi的cron服务注意ESXi的cron是BusyBox版本定期执行。例如创建一个每周日凌晨清理旧日志的作业编辑/var/spool/cron/crontabs/root文件重启后会重置需考虑持久化方法如放入/etc/rc.local.d/下的脚本中。添加一行0 2 * * 0 /bin/sh /vmfs/volumes/datastore1/scripts/clean_scratch.sh在clean_scratch.sh脚本中包含安全的清理命令。6. 高级故障排查与边缘案例即使完成了上述所有步骤在某些复杂情况下问题可能依然存在。这时就需要一些更深入的排查手段。6.1 检查并修复潜在的文件系统损坏极少数情况下/scratch所在的分区可能出现文件系统错误导致空间报告不准确。ESXi通常使用VMFAT或FAT16等文件系统用于这些分区。你可以尝试在维护模式下或通过Live CD运行文件系统检查工具。注意此操作有风险应在有备份或测试环境中进行。# 首先卸载分区如果可能且安全 umount /scratch # 使用fsck进行检查工具名和参数可能因文件系统类型而异 # 例如对于FAT文件系统可能需要使用dosfsck由于ESXi系统分区通常处于忙碌状态在线修复非常困难。更稳妥的办法是备份/scratch中有价值的数据如特定日志然后重新格式化并配置该分区。6.2 处理其他临时目录空间不足VIB事务可能不仅使用/scratch。/tmp目录本身如果未链接到/scratch/tmp也可能被使用。检查根文件系统下的/tmpdf -h /tmp如果/tmp是独立的tmpfs且空间不足你可能需要清理/tmp下的文件或者通过高级系统设置调整tmpfs的大小不推荐因为会占用内存。6.3 分析安装日志获取精确线索ESXi的软件安装过程会生成详细的日志。当安装失败时这些日志是定位根本原因的金矿。主要查看两个日志# 查看软件包管理器的操作日志 tail -f /var/log/esxupdate.log # 查看更广泛的系统日志过滤VIB相关条目 grep -i “vib\|install\|transaction” /var/log/vmkernel.log在日志中搜索错误代码如本文提到的2144200或“space”、“scratch”、“pending”等关键词往往能发现比命令行更具体的错误描述例如具体是哪个子目录空间不足。6.4 使用vSphere Lifecycle Manager (vLCM) 的考量如果你在通过vCenter Server的vLCM管理主机基准空间问题可能会以另一种形式出现。vLCM会在主机上暂存基准文件同样需要空间。确保主机的暂存配置在主机“配置”-“系统”-“高级设置”中搜索“VLCM”或“ImageConfig”指向一个有足够空间的数据存储。有时清理vLCM的缓存也能解决问题# 列出并清理vLCM缓存具体命令可能随版本变化 esxcli software sources profile list –cache esxcli software sources profile cleanup –cache7. 总结与核心要点回顾处理“The pending transaction requires xxx MB free space”错误本质上是一场与ESXi系统设计逻辑的对话。它强迫你去关注那些在平常运行时被忽略的“后台”区域。整个过程的核心思路可以归纳为定位 - 诊断 - 清理/重配 - 验证 - 预防。我个人的体会是90%的此类问题都能通过正确配置一个持久化的、空间充足的/scratch分区来预防。很多管理员在安装ESXi时只关心数据存储和虚拟机网络恰恰忘了给系统本身的“工作间”留足地盘。把这个分区当成一个重要的系统组件来对待像规划数据存储一样规划它的大小和位置能避免后续无数的麻烦。另一个深刻的教训是关于日志管理。ESXi在默认配置下日志轮转是工作的但在高负载、长时间运行或调试期间日志体积可能爆炸式增长。不要等到空间告急才去手动清理而是应该建立监控并理解哪些日志可以安全归档或删除。例如vmkwarning.log和vmkernel.log对于排查历史问题很重要但几周前的压缩日志文件在确认无关后完全可以通过自动化脚本清理。最后在执行任何VIB操作尤其是大型更新或驱动安装之前养成一个预检习惯快速检查一下df -h /scratch。这个简单的动作只需要几秒钟却能提前预警潜在的中断让你有机会在业务低峰期主动清理空间从而将计划外的运维风险降到最低。虚拟化环境的稳定性往往就藏在这些看似微不足道的日常检查之中。