早上刚到工位vCenter 的告警列表里就飘着一条扎眼的红色记录那台 DELL PowerEdge 上的数据存储 datastore1使用率已经冲到 96%状态直接进入“紧急”。干过虚拟化运维的都知道看到“紧急”两个字意味着什么——这不是某个 VM 的小困扰而是这台数据存储上所有虚拟机的读写都可能开始出问题。VMFS 存储一旦写满轻则 IO 延迟飙高重则业务虚拟机直接卡死、快照删除失败、vMotion 迁移中断一套连锁反应下来谁也顶不住。这篇文章我就把这次从告警触发、原因定位、方案选型到最终处理的完整过程拆开写。重点会覆盖几个关键环节存储告警机制与影响判断、怎么快速定位容量占用大头、DELL 虚拟化存储的扩容路径怎么选以及虚拟机磁盘扩容后客户机内部如何同步扩展分区。看到这里你就明白了这不只是“删两个文件续命”而是一套可以反复使用的存储容量应急处理流程帮你下次看到同类问题时少走弯路。1. 紧急状态出现时先想清楚这几点再做动作1.1 告警背后是什么VMFS 数据存储与容量阈值机制先说概念。VMFSVMware Virtual Machine File System是 ESXi 用来存放虚拟机文件的核心文件系统每台 VM 最关键的几个文件都在里面虚拟磁盘 vmdk、配置文件 vmx、内存交换文件 vswp还有快照产生的 delta 文件。它和普通 Windows/Linux 文件系统最大的不同就是专门为虚拟化环境做了优化多个虚拟机能共享同一个数据存储所以一旦这个“公共仓库”满了谁也跑不掉。vCenter 对数据存储的容量监控有一套默认阈值机制。以最常见的 vSphere 版本为例默认告警通常是使用率达到 85% 触发警告黄色达到 95% 触发紧急红色。不同版本、不同管理员自定义策略会有差异但逻辑一致容量快见底时系统先温柔提醒你再严厉警告你。这个机制设计得其实很合理因为虚拟化环境里容量下降往往不是线性的——快照可能在一夜之间膨胀几十 GB日志可能突然被某台异常 VM 灌满备份任务也可能瞬间吃掉大量空间。等到 100% 才算发现基本已经晚了。我自己的习惯是警告阶段就必须开始查紧急阶段只是代表“处理窗口压到最小了”。好多人看到 85% 的黄色告警觉得无所谓觉得“磁盘还大着呢”等到 95% 红字报警才慌。但存储使用率这东西和你手机上提示“存储空间不足”完全是两个概念。手机还能删删照片续两天VMFS 数据存储一旦完全写满ESXi 可能直接开始报 IOERROR那就不只是“满”的问题了而是下面要说的影响面问题。1.2 紧急与警告的差别、业务会有什么影响警告和紧急虽然都是容量告警但严重程度完全是两个档位处理策略也不同。警告阶段你还有时间做完整排查看看是快照问题、日志问题还是真实业务增长甚至能排个窗口去扩容。紧急阶段则意味着你大概率没有“慢慢调研”的余地必须先用最小代价把使用率降下来把业务风险解除再考虑根治方案。具体到影响面数据存储进入紧急状态后可能出现的故障包括但不限于数据存储上所有虚拟机的写操作延迟明显增加严重时客户机出现 IO 超时、蓝屏、文件系统只读。快照无法创建这个是常见现象更麻烦的是快照也删不掉——因为合并快照数据同样需要腾出临时空间。vMotion 迁移没有足够的目的地空间HA 故障切换可能会失败等于高可用能力直接被阉割。备份任务大面积失败因为备份系统向数据存储写入临时文件时发现没有空间。vCenter 告警刷屏操作界面卡顿ESXi 主机还有可能产生“heap memory”一类连锁异常。举个实际例子。有一次我在处理一台数据库 VM 所在的数据存储紧急告警时同事随手点了一下“删除快照”结果因为空间不足快照合并直接卡住虚拟机 MDMP中型宕机差点就发生了。所以这里必须反复强调一个原则存储进入紧急状态后先确认空间是否足够执行后续操作再动手删快照或做其他操作。宁可先小心翼翼地清理几个小文件、腾出一点余量也不要一上来就执行重型操作。2. 诊断排查找到空间被谁占满2.1 从 vCenter/ESXi 界面快速定位处理这类问题第一步永远是“看数据”而不是凭感觉猜。打开 vSphere Client路径一般是“主机和集群” → 选中集群或主机 → “存储” → “数据存储”这里能看到每个数据存储的总容量、已用空间和可用空间。如果配了 vCenter还可以直接进“监控” → “问题”看告警详情里面会写明是哪个数据存储触发了什么告警、当前使用率多少。我建议你同时打开两个视图对比看一个是数据存储视图另一个是数据中心层级下的“虚拟机”视图。后者可以按“置备空间”排序很快能看出哪些虚拟机“账面上”占用了大量空间。但要注意界面上显示的“已使用”并不等于实际物理占用。如果 VM 的虚拟磁盘是精简置备Thin Provision模式那 500GB 的 vmdk 可能只占用了 100GB 物理空间如果是厚置备Thick创建时就全部分配了。所以看容量时一定要分清“置备空间”“已使用空间”和“数据存储可用空间”这三个概念否则很容易被界面数字误导。看完界面如果还定位不到大头就要 SSH 到 ESXi 主机上用 du 命令直接扫数据存储目录。这是我最常用的办法# 列出数据存储根目录下各虚拟机占用空间按大小倒序 du -h --max-depth1 /vmfs/volumes/datastore1/ | sort -rh | head -20经过这轮扫描通常就能锁定占用最大的那几台虚拟机或文件。注意如果 ESXi 启用了 SSH操作完记得关闭避免安全风险没有启用的话也可以在 vSphere Client 里的“主机” → “服务”中临时开启用完再关。2.2 快照、稀疏磁盘与隐藏文件检查容量告警里快照是最常见的“隐形杀手”。虚拟机的快照机制本质上是在原始 vmdk 之上叠加一层 Delta 文件虚拟机持续写入时Delta 文件会不断增长。很多环境里的 VM 快照只是因为某个操作临时创建结果一挂就是几个月Delta 文件膨胀到数百 GB把数据存储直接吃满。识别快照有两种方式。第一种是图形界面右键虚拟机 → “快照” → “管理器”直接看有没有快照、快照创建时间和描述的备注。第二种是命令行SSH 到 ESXi 后进入虚拟机目录找到类似VMname-000001-delta.vmdk的文件用ls -lhS按大小排序ls -lhS /vmfs/volumes/datastore1/ | head -30这里要顺便讲解一下 vmdk 文件族的构成。每个虚拟机磁盘目录下通常能看到VMname-flat.vmdk实际数据文件、VMname.vmdk描述文件只是文本、VMname-000001-delta.vmdk快照增量文件以及VMname.vswp内存交换文件VM 运行时生成。如果你看到一个 Delta 文件大小接近甚至超过原始磁盘基本可以断定这个快照已经“长废了”需要尽快处理。另外还有个常被忽略的点vswp文件。一台配置了 64GB 内存、但资源预留又没设好的虚拟机启动后可能生成和内存等大的 vswp 文件这些文件在 VM 关机后会自动清理。如果你发现某台 VM 的目录里 vswp 特别大不要手贱去删——那是运行中的 VM 的内存交换文件删了会导致虚拟机崩溃。正确的做法是进入客户机系统提交内存、调整内存预留策略或者从根本上降低该 VM 的配置内存。2.3 硬件层确认DELL 存储与 RAID 状态软件层的容量耗尽可能是两种情况一是数据存储里真的一堆文件占满了二是底层存储设备本身就没有向 ESXi 提供足够空间。所以排查到一定程度必须把视角从 ESXi 层降到硬件层。DELL 环境里如果是服务器本地磁盘加 RAID 卡构成存储建议进入 iDRAC 管理界面或者用 Dell OpenManage 查看 PERC 控制器状态。重点看两块物理磁盘有没有 Failed 或 Predictive FailureRAID 虚拟磁盘Virtual Disk容量是否真的已经用满以及控制器的电池/电容状态是否正常。如果看到磁盘亮黄灯报警、RAID 组处于降级状态说明存储性能和容量潜力都会受影响官方固件也可能存在已知问题。遇到这种情况先把硬件故障盘处理掉再考虑扩容否则直接在故障阵列上加盘风险很大。如果是 Dell EMC 的外部存储设备比如 PowerVault、SC 系列则需要登录存储管理面板查看磁盘组/存储池的剩余空间以及卷Volume/LUN的映射关系。DELL 存储扩容涉及两个层面物理磁盘容量池是否够以及映射给 ESXi 的 LUN 容量是否需要扩展。这块和本地 RAID 的排查逻辑类似但操作入口完全不同后面第 4 部分我会结合实际操作场景细说。3. 处理方案全景扩容路线怎么选3.1 轻量手段清理快照与日志回收空间先说最基础、但也最容易见效的手段。很多人一看到容量告警就想着“加硬盘”其实很多时候三五个无用的快照和日志清掉问题就解决了一半。在处理之前建议先用一个清单把所有可回收项列出来按优先级操作优先级项目说明高过期快照Delta 文件可能占数百 GB删除前确认业务无依赖高旧 ISO/安装包数据存储上残留的镜像文件特别占空间中VM 日志/转储文件客户机系统内日志、ESXi 主机日志中的过期文件中删除的 VM 磁盘数据注意精简置备磁盘删除后空间不一定立即回收需要 UNMAP低模板与备份副本评估保留策略后再清理删除快照这个操作理论上可以联机进行但我的建议是如果是生产 VM尽量选择业务低峰期做删快照前先看一眼当前数据存储还有多少剩余空间。前面已经说过删除快照时需要把 Delta 数据合并回基础磁盘合并过程中会产生临时 IO如果空间不够操作会失败甚至卡住。稳妥的做法是先腾出快照大小 1.2 倍左右的空闲空间再执行。还有一个容易忽略的点精简置备的虚拟磁盘在客户机里删除了大量文件后ESXi 层并不会立刻回收空间。你需要对数据存储执行 UNMAP 操作才能把已删除的块真正释放回文件系统。ESXi 6.5 以上版本可以用命令手动执行esxcli storage vmfs unmap -l datastore1执行后数据存储的可用空间会在一段时间后回升。这个机制有点像 SSD 的 TRIM 命令文件系统层面标记为空闲的块最终要显式回收才能被重新分配。很多运维新手删了一堆文件后看容量没变化以为出了问题其实就是漏了这一步。3.2 物理扩容给 DELL 阵列加盘扩展虚拟磁盘如果清理完还是不够那就得进入真正的物理扩容环节。DELL 服务器的本地 RAID 扩容典型场景是这样的RAID5 虚拟磁盘由 4 块 600GB 盘组成总容量约 1.8TB用了两年已经 96% 满。计划是把 RAID 组扩展到 6 块盘或者再加一个 RAID 组。先说 RAID 组内加盘扩展。操作思路是物理插入新硬盘让 PERC 控制器识别然后在 RAID 配置界面开机按 CtrlR 进 PERC BIOS 配置工具或者直接在 iDRAC 中操作找到对应的虚拟磁盘选择扩展Expand Virtual Disk把新增物理盘的空间并入原有虚拟磁盘。要注意几个前提控制器固件版本要支持在线扩展。DELL 的 PERC H730、H740P 这类主流卡一般都支持但老型号兼容性要提前查。扩展过程中 RAID 组会有 IO 压力建议在低峰期操作。扩展前务必检查 RAID 组状态确保当前不是降级状态Degraded。降级时做扩展一旦中断数据风险极高。如果物理槽位不够考虑用热备盘顶替、更换更大容量单盘或者在外部盘柜上新增存储再映射给 ESXi。另一种路线是新增一个 RAID 组VD2把它作为一个全新的 LUN 映射给 ESXi。这样做的好处是不影响原来存储上的数据缺点是会产生新的数据存储需要配合 Storage vMotion 做虚拟机迁移。两种方案没有绝对优劣取决于当前存储硬件结构和业务窗口。如果环境里已经有独立的 DELL 存储设备则更推荐在存储侧新建卷映射出来而不是在服务器本地 RAID 上“抠”空间。3.3 在线扩容数据存储扩展 VMFS 与新增数据存储物理层做完扩容后ESXi 侧还需要一系列操作才能让新空间真正可用。许多新手在这步容易卡住底层 RAID 虚拟磁盘扩容了怎么 ESXi 数据存储容量还是原来的样子因为这个扩容不是自动的需要“手动确认”。第一步让 ESXi 重新扫描存储适配器。在 vSphere Client 中右键主机 → “存储” → “重新扫描”或者用命令行esxcli storage core adapter rescan --all扫描完成确认 LUN 大小已经从原来的 1.8TB 变成 2.4TB 或别的目标值。第二步扩展 VMFS 数据存储。选中数据存储 → “属性” → “增加容量” → “扩展”选择未分配空间即可。注意扩展 VMFS 只能增加容量不能缩小这是文件系统的“单向增长”特性操作前心里要有数。如果底层控制器不能扩展原有 LUN比如新增的物理盘被做成了独立虚拟磁盘 VD2那就只能新建数据存储然后用 Storage vMotion 把部分虚拟机迁移过去实现负载均衡。这里我把“扩展 VMFS”和“新建数据存储 vMotion”做个对比方便你根据场景选择对比项扩展 VMFS新建数据存储 Storage vMotion操作复杂度低两步完成较高需要规划迁移顺序对现有 VM 影响几乎无感迁移过程中有 IO 切换需谨慎适用场景底层 LUN 容量已扩展底层新增了独立 LUN空间管理所有 VM 继续共享一个数据存储可做业务隔离、按优先级分布风险点只能扩大不能缩小迁移失败需回滚实际生产中我更推荐混合方案能扩的扩扩不了的走 vMotion。毕竟所有 VM 挤在一个数据存储里本身就不是健康的架构趁扩容的机会顺便做一次存储分布梳理一举两得。3.4 单台虚拟机 vmdk 扩容的正确姿势还有一种常见场景数据存储整体还有空间但某台 VM 内部磁盘满了。比如数据库服务器的 D 盘当初只分了 200GB现在业务数据涨到了 250GB客户机系统里各种报“磁盘空间不足”。这种场景下要在 ESXi 层先给虚拟磁盘扩容再进客户机系统扩展分区。ESXi 层操作很简单编辑虚拟机设置 → 选择目标硬盘 → 在“大小”栏填上新的容量值。这里要注意三个限制VMFS5 数据存储上单个虚拟磁盘vmdk最大不能超过 2TB超过会导致创建或扩容失败。VMFS6 对单盘的上限提高到 62TB但前提是数据存储格式为 VMFS6且虚拟机硬件版本支持。虚拟磁盘只能扩大不能在线缩小。想减容需要备份、重建、数据迁移成本很高。ESXi 层扩展完成后最关键的一步是进入客户机系统做分区扩展否则虚拟机内部依然看不到新空间。我就见过有人只在 vSphere 界面把磁盘从 200GB 改成 500GB然后客户机里怎么都不识别跑来问我是不是操作错了——其实只是忘了做客户机侧扩展。具体操作因操作系统而异Windows 和 Linux 略有不同。Windows 系统比较省事。右键“此电脑” → “管理” → “磁盘管理”如果新空间在现有分区后面直接右键目标分区 → “扩展卷”一路下一步即可。如果扩展卷按钮是灰色的多半是因为新空间和现有分区不相邻中间隔了恢复分区之类需要借助 Diskpart 或第三方工具处理。命令行方式适合批量环境diskpart list disk select disk 0 list volume select volume 2 extendLinux 系统按分区类型区分。如果是 LVM 管理的根分区标准流程是用 growpart 扩展物理分区 → pvresize 刷新 PV → lvextend 扩展 LV → resize2fsext4或 xfs_growfsxfs扩展文件系统。以 CentOS/RHEL 常见的 LVM 布局为例# 假设根分区物理盘为 /dev/sda根分区占用第3个分区 growpart /dev/sda 3 pvresize /dev/sda3 lvextend -l 100%FREE /dev/mapper/centos-root resize2fs /dev/mapper/centos-rootXFS 文件系统对应的最后一步是xfs_growfs /区别在于 resize2fs 用设备路径xfs_growfs 用挂载点。实际操作前建议先df -h和lsblk看清楚分区布局别想当然地按模板套——真有人把一个非 LVM 裸分区当成 LVM 去操作结果分区表直接乱了。4. 实操记录一次 DELL 虚拟化存储紧急状态处理全过程4.1 现场第一动作释放空间的应急操作这次的故障环境是一家单位的虚拟化集群两台 DELL PowerEdge 服务器ESXi 7.0 版本接的是 DELL 存储的 LUN数据存储总容量 4TB告警时已用 3.84TB使用率 96%。vCenter 告警显示 datastore1 进入紧急状态数据存储上运行着大约 15 台虚拟机其中有两台是生产数据库。我到现场后的第一件事不是急着扩容而是先确认有没有 VM 已经受影响。打开每台 VM 的任务列表看有没有 IO 报错再通过客户机系统看磁盘是否正常响应。确认业务还活着之后才开始处理容量问题。第二步扫空间。用du -h --max-depth1 /vmfs/volumes/datastore1/一列瞬间就定位到了问题有两台 Windows 测试虚拟机各自挂了 1.2TB 和 800GB 的快照Delta 文件加起来占了将近 2TB。查了虚拟机备注这两台是三个月前上的测试环境快照是当时的部署验证创建的后续根本没有改动完全可以直接删。在低峰期我先把 800GB 快照的那台删了删除过程持续了十几分钟好在存储没有彻底写满删除没有中断。空间被释放后datastore1 的使用率降到了 88% 左右“紧急”状态消除警报从红色变成黄色。这就是应急第一动作的作用——先别想大工程找最大的快照清理把红字压掉为后续方案争取时间。4.2 底层容量扩展操作示例告警解除只是开始88% 的使用率依然偏高且那两台测试 VM 后续还需要继续运行所以必须做真正的扩容。因为 ESXi 使用的 LUN 来自于 DELL 存储我登录 DELL 存储管理界面先查看磁盘组 Pool 的剩余空间情况。存储上有两个磁盘组其中一个还有大约 4TB 空闲容量。在存储侧的操作是选中目标卷Volume执行扩展卷容量把 LUN 从 4TB 扩展到 6TB。这个过程对 ESXi 是透明无损的底层 LUN 变大后ESXi 重新扫描适配器就能看到新容量。如果你的环境是 DELL 本地 RAID这里对应的操作就是前面说的 PERC 扩展 Virtual Disk——原理一致入口不同。扫描完成后vSphere Client 里可以看到数据存储容量已经变成 6TB但可用空间并没有同步增加因为 VMFS 还没扩。接下来就是右键数据存储选择“增加容量”在向导里把 LUN 上新增的 2TB 全部扩展进现有 VMFS 文件系统。整个扩展过程不到一分钟业务虚拟机全程无感。4.3 验证与业务恢复扩容完成后不能直接拍拍屁股走人必须做一轮完整验证确认环境真正恢复健康。我会按固定套路走一遍在 vSphere Client 检查数据存储总容量、可用容量是否与预期一致。抽查几台关键 VM确认客户机系统 IO 正常、网络连接正常、应用日志无新增报错。执行一次快速快照删除测试验证存储有足够空间支持合并操作。检查备份任务确认当晚的增量备份可以正常写入。最后再看一眼 vCenter 告警中心确认紧急告警已消除。验证完毕还要做的事是“善后记录”。我会把本次问题的时间线、原因、处理动作、扩容后的容量现状都记录下来更新到环境文档里。这不是走形式而是为了下次再遇到类似问题时团队不用重新把坑踩一遍。5. 常见问题与避坑经验5.1 快照删不掉怎么办快照删除失败是存储容量问题里最揪心的一种情况。明明想释放空间结果删快照反而把 VM 搞宕机这种事故很多。常见原因有三个存储空间不足导致合并无法完成、快照文件损坏、虚拟机本身故障或锁文件残留。处理思路按顺序来。第一先看存储还有多少空间。删除快照是一个写入密集型操作需要把 Delta 数据合并回基础盘过程中需要可用的临时空间。如果空间不足就先清理其他无关文件、或者迁移一台无关紧要的 VM 到其他数据存储给合并留出余量。第二如果快照文件损坏不要直接删 Delta 文件那样会让 VM 无法启动。正确做法是先在 vSphere 里尝试“快照” → “全部删除”如果图形界面不行再考虑用命令vim-cmd vmsvc/snapshot.removeall从底层执行。第三如果仍然失败最安全的手段是用 Storage vMotion 把 VM 迁移到另一数据存储迁移完成后快照链会重建问题自然解除。这里必须说一句永远不要直接进数据存储目录手动删除快照 Delta 文件除非你已经准备好做 VM 数据恢复。我见过不止一次有人图省事手删 Delta 文件结果虚拟机的快照链断裂启动直接报 “Parent disk not found”最后只能靠备份恢复数据代价巨大。5.2 vmdk 扩容后客户机看不到新空间这是一个出现频率极高的“二次故障”。ESXi 层扩了容量、客户机里看不到大概率是分区扩展没做或者做的方式不对。先说 Windows。打开“磁盘管理”如果看到磁盘后面有一段未分配空间右键分区选“扩展卷”就能处理如果扩展卷是灰色的通常是因为分区之间存在恢复分区或系统保留分区导致新空间不连续。可以考虑用 Diskpart 对卷执行 extend再不行就得评估数据后重建分区或使用第三方分区工具。Linux 的情况要复杂一点特别是根分区。很多人扩容 vmdk 后在客户机里df -h一看没变化就开始慌了。正确路径是lsblk # 看物理盘和分区的新大小 growpart /dev/sda 3 # 如果 sda3 是根分区所在的分区 pvresize /dev/sda3 # 如果根分区是 LVM lvextend -l 100%FREE /dev/mapper/xx-root resize2fs /dev/mapper/xx-root # ext4如果根分区不是 LVM 而是普通分区那就需要resize2fs /dev/sda3之类的操作变体。前提是分区表和文件系统支持在线扩展。xfs 用户记得用xfs_growfs而不是 resize2fs。每次看到有人拿 resize2fs 处理 xfs我都替他捏把汗虽然新版工具可能有一些兼容处理但核心逻辑必须搞对。5.3 扩容只加不减规划得提前做虚拟磁盘扩容有个硬性特点只加不减。虽然大版本之后 VMware 推出过“Reconfigure disk”相关功能生产环境实际可操作的“在线缩容”方案依然非常有限常见方法基本都要通过克隆、备份恢复或者第三方转换工具实现操作复杂不说风险还高。所以在给 VM 分配初始磁盘时一定要结合业务预估成长空间宁可先多分配也别让磁盘容量成为瓶颈。另一个相关坑是“滥用精简置备”。精简置备确实省空间但反过来也容易让管理员产生“容量充足”的错觉。比如 10 台 VM 每个申请了 1TB 的精简磁盘数据存储只有 4TB看起来置备空间 10TB实际用了 2TB似乎很安全。但业务数据一旦快速增长几周之内就可能把数据存储吃满而你根本不知道是哪台 VM 先“胖”起来。所以精简置备环境监控和预警必须更勤而不是更松。5.4 容量预警应该怎么设预警阈值不要死守默认值要根据实际数据存储的大小和业务特点来调。比如一个 1TB 的小数据存储85% 警告、95% 紧急可能勉强够用因为几个大文件就可能导致容量剧变而对于一个 10TB 的大数据存储95% 紧急时还有 500GB 可用空间处理窗口会长得多。我的建议是警告阈值设置在 75%80%紧急阈值设置在 90%92%具体数值结合快照频率和最大单个 vmdk 大小综合判断。总之要保证“告警触发后我还有足够时间去排查和处理”。监控手段上可以配合 PowerCLI 脚本做定期扫描把容量数据导出来做趋势分析。下面这个脚本是我的标准做法Get-Datastore | Select-Object Name, {NCapacityGB;E{[math]::Round($_.CapacityGB,2)}}, {NFreeGB;E{[math]::Round($_.FreeSpaceGB,2)}}, {NUsedPercent;E{[math]::Round(($_.CapacityGB - $_.FreeSpaceGB) / $_.CapacityGB * 100, 2)}}写个计划任务每周跑一次输出结果直接进邮件或导入报表系统。容量是慢慢涨的及早发现趋势扩不扩容、什么时候扩心里都有底而不是等 vCenter 红字报警被业务部门追着问。处理完这轮紧急告警后我给自己定了一条规矩每周一用脚本扫一遍所有数据存储容量哪个超过 80% 就提前规划扩容快照超过 72 小时不合并的 VM必须找负责人确认原因。说句实在话虚拟化环境的大多数存储故障都是“慢慢变满”的过程救火处理当然要会但更值钱的是把火掐在冒烟之前。希望这次的完整过程能在你下次看到红色告警时帮你少走几步弯路。