1. 问题概述当安装VIB时遭遇“需要XXX MB空闲空间”错误在虚拟化基础设施的运维工作中尤其是在使用VMware vSphere系列产品时我们经常会通过安装VIBvSphere Installation Bundle文件来为ESXi主机添加驱动、CIM提供程序或进行安全补丁升级。这看似是一个简单的操作但很多管理员包括我自己都曾在某个深夜被一条看似直白却令人困惑的错误信息拦住去路“The pending transaction requires xxx MB free space”。这条错误信息直接翻译过来是“待处理的事务需要XXX MB的可用空间”它通常出现在你通过esxcli software vib install命令或vSphere Client尝试安装、更新VIB时。这个错误的表象是磁盘空间不足但它的内核往往比“清理磁盘”要复杂得多。它指向的是ESXi系统内部一个用于管理软件事务的临时工作区——暂存区Scratch Partition或事务回滚空间不足。简单地把这个错误等同于“/”根分区空间不足然后去删除一些日志文件很可能无法解决问题甚至可能误删关键文件导致系统不稳定。我记得有一次在为一个客户升级网卡驱动时遇到这个报错当时第一反应是查看根分区发现还有好几个GB的空间一下就懵了。这促使我深入研究了ESXi的软件安装机制才弄明白其中的门道。本文将彻底拆解这个错误对应VMware知识库文章2144200不仅告诉你如何快速解决更重要的是我会带你理解ESXi软件管理的底层逻辑包括暂存区的作用、空间计算方式、以及如何从根本上规划和避免此类问题。无论你是正在紧急排障还是想未雨绸缪这些从实战中踩坑总结出来的经验都能让你在面对ESXi软件生命周期管理时更加从容。2. 核心原理ESXi软件安装与暂存区机制深度解析要根治问题必须先理解原理。我们不能把ESXi简单地看作一个Linux发行版它的设计目标是高度可靠、精简且无状态的。其软件管理架构也围绕这个目标构建。2.1 事务性安装与回滚需求ESXi的软件安装包括VIB和ESXi镜像更新是事务性的。这意味着整个安装过程被视为一个原子操作要么完全成功系统进入新状态要么完全失败系统回滚到安装前的原始状态。这种设计保证了系统的稳定性避免了安装部分文件导致的系统损坏。为了实现回滚ESXi需要在安装开始前预留出足够的空间来存放两样关键东西新的VIB包文件本身需要被解压并暂存。当前系统中将被替换的旧VIB的备份这是回滚的“后悔药”。如果安装失败系统需要用这些备份文件恢复原状。这个用于存放“新文件”和“旧备份”的临时工作区域就是引发错误的焦点——暂存区。2.2 暂存区的位置与识别暂存区并不是一个固定名称的分区。ESXi会按优先级顺序寻找并使用以下位置作为暂存区专用暂存分区如果在安装ESXi时在磁盘上划分了一个独立的“暂存分区”通常标记为Scratch系统会优先使用它。这是最佳实践。/tmp/scratch目录如果存在会使用此目录。/scratch目录这是一个指向实际暂存位置的符号链接。你可以通过SSH连接到ESXi主机运行ls -la /scratch来查看它当前指向哪里。根分区/下的临时空间如果以上都未配置或不可用ESXi会尝试使用根文件系统的剩余空间。这通常是最不理想的情况因为根分区本身空间有限。你可以通过以下命令快速检查当前暂存区的配置和使用情况# 查看/scratch链接指向的实际路径 df -h /scratch # 查看系统识别的暂存区信息更详细 esxcli system syslog config get | grep -i scratch # 或者 vim-cmd hostsvc/advopt/query ScratchConfig.ConfiguredScratchLocation | grep stringValue2.3 空间计算逻辑与错误触发错误信息中的“xxx MB”不是凭空产生的。ESXi安装程序会进行一个预估计算所需暂存空间 ≈ 新VIB包解压后大小 将被替换的旧VIB文件总大小 安全冗余量这个“安全冗余量”是很多管理员忽略的关键。ESXi为了确保事务绝对可靠会在计算出的理论值上额外增加一部分缓冲空间通常是百分比或固定值。因此即使你查看暂存区空间只差几十MB安装程序也可能因为预留缓冲不足而报错。注意这里有一个常见的思维误区。错误提示的是“pending transaction”待处理事务需要空间而不是“目标安装位置”需要空间。即使你要安装VIB的模块如/usr/lib/vmware所在分区空间充足只要暂存区空间不足事务就无法开始安装就会失败。这就是为什么只检查根分区常常找不到原因。3. 问题排查与解决一套组合拳当错误出现时不要慌张。按照以下流程操作可以系统性地定位和解决问题。我习惯称之为“空间问题排查四步法”。3.1 第一步精准诊断——确认空间瓶颈到底在哪首先我们需要全面了解系统的磁盘布局和空间使用情况。# 1. 查看所有文件系统的磁盘使用情况人类可读格式 df -h # 2. 重点关注根分区和暂存区 df -h / /scratch /tmp/scratch # 3. 如果/scratch是链接追查其真实位置 ls -la /scratch df -h [上一步命令显示的真实路径] # 4. 查看哪个目录或文件占用了最多空间在空间紧张的分区上执行 # 例如如果根分区/空间紧张 cd / du -h --max-depth1 | sort -hr | head -20通过以上命令你可以清晰地看到暂存区实际位于何处是独立分区、/tmp/scratch还是根分区下。该位置剩余空间是多少。是什么文件或目录占用了大量空间常见的有旧日志、核心转储文件、临时更新包等。3.2 第二步紧急清理——安全地释放空间根据诊断结果针对性地进行清理。务必谨慎避免删除系统运行必需的文件。场景A暂存区位于独立分区或/scratch这种情况比较好处理因为通常这里只存放临时文件。手动删除残留的安装临时文件rm -rf /scratch/*(在确认该目录下无重要文件后)。清理旧日志/scratch/log目录下可能有过期的日志文件。场景B暂存区使用的是根分区/空间最常见也是最棘手的情况根分区空间非常宝贵清理时需要格外小心。清理核心转储文件这些文件通常很大且以vmkernel-zdump-开头。# 查找并列出核心转储文件 find /var/core -name vmkernel-zdump-* -type f 2/dev/null # 如果确认可以删除比如是过去的问题产生的可以移除 # rm -f /var/core/vmkernel-zdump-*重要提示在删除核心转储文件前最好先确认其产生原因是否已解决。它们是诊断严重系统故障的关键。清理旧的支持包Support Bundles通过vSphere Client或命令行生成的支持包可能会被保存在默认位置。ls -la /var/tmp/vmware-*.tgz /var/tmp/esx-*.tgz 2/dev/null # 确认后可删除清理/tmp目录一些临时文件可能残留。ls -lt /tmp # 删除明显的、非当前使用的临时文件轮转或清理大型日志文件/var/log下的日志如vmksummary.log,vmkwarning.log,hostd.log等可能会增长。# 查看大日志文件 du -h /var/log/*.log | sort -hr | head -10 # 不要直接删除当前正在写入的日志文件可以使用logrotate或清空内容 # 例如清空一个非常大的旧日志确保服务不会正在写入 # cat /dev/null /var/log/某个非常大的旧日志.log场景CVIB安装包本身巨大有时你要安装的离线补丁包或驱动包本身就非常大比如完整的ESXi镜像更新包。此时除了清理暂存区还需要确保用于上传VIB包的临时位置也有足够空间。当通过vSphere Client上传时文件会先传到ESXi主机的某个临时目录如/tmp这同样会消耗空间。3.3 第三步配置优化——设置专用暂存分区治本之策临时清理只能救急。要一劳永逸地避免此问题最佳实践是为ESXi主机配置一个专用的、容量充足的暂存分区。这通常在ESXi初始安装时完成但也可以在后期添加。方法一在安装ESXi时配置在安装向导的磁盘布局步骤中手动分区并专门划出一个大小为4-8GB的分区将其类型设置为“VMFS”或“暂存区”。这个大小对于绝大多数VIB和补丁安装来说都绰绰有余。方法二为已运行的主机添加暂存分区通过命令行这需要有一块未使用的本地磁盘或持久内存盘如USB/SD卡但不推荐用于生产环境因为易损坏。在磁盘上创建一个新分区假设磁盘为/dev/disks/naa.xxx。格式化为VMFS-L一种轻量级文件系统适用于暂存区partedUtil mklabel /dev/disks/naa.xxx msdos partedUtil setptbl /dev/disks/naa.xxx msdos partedUtil create /dev/disks/naa.xxx primary 2048 100% vmkfstools -C vmfsl -S scratch /dev/disks/naa.xxx:1将新分区挂载到/scratchesxcli system syslog config set --logdir/vmfs/volumes/[新分区ID]/ # 或者更直接地创建链接重启可能失效建议用上面命令 # ln -sfn /vmfs/volumes/[新分区ID] /scratch重启主机使配置永久生效。方法三将暂存区重定向到共享存储或内存盘非持久化谨慎使用共享存储可以将暂存区设置到VMFS数据存储上。但不推荐因为这会增加存储网络的负载并在存储故障时影响主机操作。esxcli system syslog config set --logdir[Datastore路径]/scratch内存盘将暂存区指向/tmp这完全依赖于主机内存。极度不推荐用于生产环境因为大事务可能耗尽内存导致主机崩溃。3.4 第四步安装技巧——绕过或最小化空间使用如果空间问题暂时无法彻底解决但安装又必须进行可以尝试以下技巧使用--no-sig-check和--force参数谨慎有时安装程序在检查VIB签名时会产生额外的临时开销。使用这些参数可以跳过某些检查步骤可能减少临时空间的使用。但这会降低安全性仅在信任VIB来源且紧急情况下使用。esxcli software vib install -v /path/to/your.vib --no-sig-check --force分步安装如果是一个包含多个VIB的大补丁包尝试查看清单文件是否可以分批安装其中最关键的部分。通过vSphere Lifecycle Manager (vLCM)进行对于vSphere 7.0如果主机由vLCM管理更新过程可能由vCenter Server协调它有时能更好地处理资源问题但本质问题仍需解决。4. 实战案例与深度避坑指南理论说再多不如看一个真实的排障案例。去年我遇到一个客户环境在更新一个重要的安全补丁时多台主机接连报出“需要1200MB空闲空间”的错误。4.1 案例复盘连锁反应与根本原因初始状态客户环境有20台ESXi 6.7主机安装时未配置独立暂存分区暂存区默认指向根分区。根分区大小为5GB日常剩余约1.8GB。触发事件需要安装一个大型的驱动更新包该包解压后约800MB需要替换的旧驱动约300MB。加上冗余缓冲预估需要空间超过1.2GB。问题爆发第一台主机安装失败报错。管理员尝试清理/var/log下的日志释放了300MB再次安装仍然失败。因为清理后空间约2.1GB但仍未达到安装程序内部计算的“安全阈值”。错误操作管理员转而尝试删除/bootbank下的一些旧引导文件导致一台主机重启后无法引导引发了更严重的事故。根本解决我介入后首先通过esxcli software vib install --dry-run结合--depot参数模拟安装估算出更精确的空间需求。然后我为所有主机制定了一个维护窗口计划将暂存区临时重定向到一个临时挂载的、空间充足的NFS共享仅用于此次更新。分批实施更新每台主机更新前通过脚本自动清理核心转储和旧支持包。更新完成后在下次计划停机时为每台主机的本地磁盘添加一个8GB的专用暂存分区并永久修改配置。4.2 避坑清单与最佳实践根据无数次实战教训我总结了以下“要”与“不要”一定要做的安装时规划分区在新装ESXi时务必划分一个独立的4-8GB暂存分区。这是成本最低、收益最高的预防措施。定期监控空间将/scratch和/分区的空间使用率纳入日常监控如通过vROps或Zabbix设置阈值告警例如80%。使用--dry-run预览在执行任何安装前使用esxcli software vib install --dry-run命令。这个“模拟运行”模式会列出将要安装、升级或移除的VIB并有时会提前暴露空间不足的问题让你有机会提前准备。清理有术建立定期的日志维护规程。使用logrotate配置或ESXi内置的日志管理功能避免日志无限增长。对于支持包在下载到本地后及时从ESXi主机上删除。千万不要做的不要盲目删除/bootbank或/altbootbank下的文件这是系统的引导分区删除文件会导致主机无法启动是灾难性的。不要随意清空正在写入的日志文件使用cat /dev/null file.log比直接rm file.log更安全因为后者可能会被正在运行的服务重新创建而前者会保留文件句柄。但最好还是通过服务重启或日志轮转来管理。不要长期使用/tmp或内存盘作为暂存区这是不稳定的源头。/tmp在内存中主机重启后内容丢失虽无大碍但大事务可能耗尽内存。内存盘同理且性能并非最佳。不要忽略“安全冗余量”即使计算看起来空间够也要多预留至少20%-30%的余量。ESXi内部算法可能比你估算的更保守。4.3 高级排查当常规方法全部失效如果上述所有方法都试过了空间确实足够但错误依旧那么可能需要考虑一些更深层次的问题文件系统锁或权限问题极少数情况下可能是暂存区目录的权限不正确或者有残留的文件锁阻止了新临时文件的创建。尝试重启主机可以清除大多数锁。检查/scratch的权限是否为drwxrwxrwt粘滞位很重要。软件源问题如果你是从在线存储库安装可能是存储库的元数据文件损坏或不完整导致本地缓存时出现问题。可以尝试清理软件源缓存rm -rf /var/cache/esxcli/*然后重试。ESXi系统卷损坏非常罕见但文件系统错误可能导致空间计算错误。可以尝试进入ESXi恢复模式或使用vmkfstools检查文件系统但这属于高风险操作需在VMware支持指导下进行。5. 总结与个人体会处理“The pending transaction requires xxx MB free space”错误的过程本质上是对ESXi“无状态”设计哲学的一次深入理解。这个系统为了追求极致的可靠性和可维护性将状态变更软件安装设计成了一个严谨的事务。暂存区就是这个事务的“预备舞台”和“安全气囊”。我个人的最深体会是在ESXi的世界里预防远比治疗重要。花30分钟在安装系统时规划好分区布局未来可能节省你数小时的紧急排障时间并避免业务中断的风险。把这个错误看作一个善意的提醒它迫使你去审视主机的存储配置是否符合最佳实践。最后分享一个我常用的快速检查脚本可以放到你的运维工具箱里。它不会自动修复问题但能给你一个清晰的概览#!/bin/sh # esxi_scratch_check.sh echo “ ESXi主机暂存区与磁盘空间检查 ” echo “- 主机名: $(hostname)” echo “- 时间: $(date)” echo “” echo “1. 暂存区配置信息:” esxcli system syslog config get | grep -E “Scratch|Log” echo “” echo “2. 关键分区空间使用:” df -h / /scratch /tmp/scratch /bootbank 2/dev/null | grep -v Filesystem echo “” echo “3. /scratch 实际位置:” ls -la /scratch echo “” echo “4. 根分区下可能的大文件/目录 (Top 10):” du -h -d 1 / 2/dev/null | sort -hr | head -11 | tail -10 echo “” echo “检查完成。建议确保 /scratch 指向独立分区且剩余空间 2GB。”把这个脚本存到ESXi主机的/tmp下用sh /tmp/esxi_scratch_check.sh执行你就能对空间状况一目了然。希望这些从实战中摸爬滚打出来的经验能帮你下次再遇到这个错误时心里有底手上有招。
