一、 问题描述及背景
1. 描述
一套7.0的vSAN集群,ESXI版本为: 7.0.3, 23794027,在一次上传ISO镜像时失败,报错信息显示没有足够的空间。

2. 确认存储空间足够
上传ISO镜像大小为6GB左右,vSAN可用空间充足。

二、 日志分析过程
1. 导出ESXi日志分析
通过日志定位到失败的记录,报错中提到“Max no space retries (10) exceeded for caller Fil6_FileIOInt (status 'No space left on device')”(日志时间需要+8)

2. ESXi日志分析
通过日志中的报错信息发现同官方记录的一个7.0U3c之前版本的BUG非常类似。
(1) KB中描述的现象及错误日志

(2) KB中描述的失败原因

(3) KB中给出的修复建议

参考KB:
参考KB:http://knowledge.broadcom.com/external/article/318518/storage-vmotion-fails-with-error-no-spac.html
(4) 官方对于LFB和SLB的相关解释

3. 分析总结
本次出问题的并非是VMFS6的datestore存储,而是vSAN分布式存储,日志中也提及了SFB 和 LFB的TOTAL、FREE、Notavailable相关使用情况且LFB的(numFreeResources:0)空闲资源已经为0,与问题现象符合。很明显vSAN中也存在这两个概念,所以判定该问题是vSAN的一个BUG。

四、 事件处理后续
由于ESXI的版本为最新版本,官方也并未发布修复补丁,联系了原厂相关人员也暂时没有解决办法。
1. 临时处理措施
目前采用的措施为删除部分大文件,以释放相关的LFB、SFB的free资源。随后可重新上传新文件
2. 问题总结
当前并未发现会影响虚拟机和磁盘的新建交付(可能vSAN存储策略默认都是精简盘的缘故,厚置备可能会受影响),还有对于此类关于存储容量的问题,不要仅仅只参考文件系统的剩余空间大小。