1. 问题现象与背景解析上周五凌晨2点37分监控系统突然狂发告警短信——某台运行关键业务的ESXi主机突然失去响应。当我顶着黑眼圈连上iDRAC查看时熟悉的紫色管理界面已经变成了满屏的root filesystem is full错误。这种场景对于虚拟化运维人员来说就像厨师看到灶台着火一样让人血压飙升。ESXi作为Type-1型裸机虚拟化管理程序其精简Linux内核会将/tmp、/var/log等目录挂载到内存中的ramdisk。这种设计原本是为了提升性能但当日志疯狂增长占满整个root文件系统时默认只有120MB左右轻则无法创建新虚拟机重则直接导致宿主机崩溃。我管理的这套vSphere 7.0 U3环境就遇到了典型的/根分区爆满问题具体表现为无法通过SSH上传文件No space left on devicevCenter显示主机无响应控制台执行df -h显示/挂载点使用率100%2. 紧急处理与临时扩容2.1 应急清理步骤面对这种紧急情况我的处理优先级是先恢复业务再根治问题。通过iDRAC远程控制台依次执行# 查看各目录占用情况注意-h参数以人类可读格式显示 du -h -x --max-depth1 / | sort -h # 发现/var/log/vmware/占用83MB # 使用logrotate立即轮转日志 /usr/lib/vmware/vm-support/bin/logrotate --force /etc/vmware/logrotate.conf # 清理core dump文件如果有 find /var/core -type f -name *.gz -exec rm -f {} \; # 最后确认空间释放情况 df -h重要提示绝对不要直接删除/var/log/下的日志文件这可能导致ESXi记录中断。应该使用内置的logrotate工具安全轮转。2.2 临时扩大ramdisk如果清理后空间仍然紧张可以动态调整ramdisk大小重启后失效# 查看当前tmpfs配置 esxcli system visorfs ramdisk list # 将root分区从默认的120MB扩展到200MB esxcli system visorfs ramdisk set -m 200 -t root这个临时方案能争取到故障排查时间但真正的解决之道在于...3. 根因分析与长效解决方案3.1 日志暴增的常见诱因通过分析/var/log/vmware/vpxa.log发现根本原因是某台Windows VM的VMware Tools持续报错导致每秒生成数十条日志记录。具体场景包括虚拟机硬件版本过旧如仍在使用HWv10客户机时钟与主机不同步超过5分钟存储链路闪断触发SCSI重置风暴3.2 永久性配置调整3.2.1 修改ramdisk大小需主机重启编辑ESXi启动参数通过SSH连接主机编辑/bootbank/boot.cfgvi /bootbank/boot.cfg在kernelopt行尾追加visorfs.rootMaxSize200M保存后执行auto-backup.sh3.2.2 日志管理强化方案在/etc/vmware/logrotate.conf中增加以下策略/var/log/vmware/*.log { rotate 5 size 10M missingok compress delaycompress sharedscripts postrotate /usr/lib/vmware/vm-support/bin/logrotate --force /etc/vmware/logrotate.conf endscript }3.2.3 高级日志重定向对于长期运行的集群建议将日志外接到集中存储esxcli system syslog config set --loghostudp://192.168.1.100:514 esxcli system syslog reload4. 深度防御与监控策略4.1 关键指标监控清单在vRealize Operations中配置以下告警阈值指标名称警告阈值严重阈值检测频率Storage/root_used70%85%5分钟Storage/var_log_used60%75%15分钟Disk/log_write_rate100KB/s500KB/s1分钟4.2 自动化维护脚本创建定期执行的shell脚本存放到/vmfs/volumes/datastore1/scripts/#!/bin/sh # 清理超过30天的压缩日志 find /var/log -name *.gz -mtime 30 -exec rm -f {} \; # 检查VMware Tools状态 esxcli software vib list | grep tools /tmp/tools_check.txt if grep -q version:mismatch /tmp/tools_check.txt; then echo $(date): VMware Tools版本不匹配 /var/log/esxi_maintenance.log # 触发邮件告警... fi # 强制日志轮转 /usr/lib/vmware/vm-support/bin/logrotate --force /etc/vmware/logrotate.conf5. 故障复盘与经验总结这次事故暴露出三个关键教训日志监控盲区我们配置了CPU/内存告警却忽略了root分区这种小容量关键路径。现在所有ESXi主机都在/vmfs/volumes上部署了日志监控agent。默认配置陷阱ESXi的120MB root分区对现代环境来说太小。新部署规范已调整为200MB并在模板中预置优化过的logrotate配置。连锁反应防御某个VM的异常能拖垮整个主机这促使我们实施了更严格的VM健康检查策略包括每周自动扫描HW版本过低的VM客户机时钟偏差超过3分钟自动校正存储链路状态纳入统一监控那个深夜的紧急处理让我深刻认识到在虚拟化环境中越是底层的存储问题破坏力往往越大。现在我的巡检清单上df -h已经和内存使用率、CPU负载一样成为了每日必查项。