VMware存储卷扩展实战：从底层原理到VMFS在线扩容全解析

1. 存储卷的底层逻辑：先搞清楚“卷”到底是什么

讲存储卷之前，先想一个问题：你在虚拟机里看到的C盘、D盘，和你在ESXi主机上看到的“datastore1”到底差了多少层？

答案是：差了很多层，但很多运维干了几年也没认真琢磨过这件事。实际上，虚拟机看到的一块100GB的磁盘，可能是ESXi主机上一个叫“VMFS存储卷”的东西里面存放的一个vmdk文件，而这个vmdk文件在物理层面可能是从一组RAID磁盘阵列上切出来的LUN，也可能是NAS设备通过NFS导出的一份共享目录，还有可能是本地SATA盘上的一个大分区。

存储卷，简单理解就是“存储系统提供给上层使用的一块逻辑空间”。它屏蔽了底层的物理实现——你的物理存储是一块盘、十块盘还是一个分布式集群，对上层来说都是一块可以格式化、可以放文件的“空地”。

1.1 为什么同一个词在不同场景指的东西完全不同

这里特别容易踩坑。大家嘴上都说“存储卷”，但在不同产品、不同架构里，这个词对应的对象完全不一样：

• 在VMware ESXi里，存储卷通常指一个VMFS文件系统或NFS挂载点，也叫数据存储（datastore）。
• 在Linux的LVM里，存储卷指逻辑卷（Logical Volume），由卷组（Volume Group）划分而来。
• 在Docker里，存储卷（Volume）是宿主机上专门为容器持久化数据准备的目录。
• 在云平台上，存储卷往往是云硬盘，通过块存储服务挂载到云服务器上。

这篇文章我们以虚拟化/超融合场景为主来讲，因为最近我正好在帮客户梳理VMware存储架构，也遇到了“vmware扩展vmfs存储卷”这个高频操作需求，干脆就顺着这个话题把存储卷从头捋一遍。

2. 最常用的四类存储卷：本地盘、SAN卷、NAS卷、虚拟卷

做虚拟化的人每天打交道的基本就是这四种存储卷。很多人只知其名不知其所以然，我逐个说一下它们的内在工作方式，以及各自的适用边界。

2.1 本地盘存储卷：最直接也最容易“玩脱”

本地盘就是把ESXi主机自己物理硬盘刨出一块空间，格式化成VMFS文件系统，当作数据存储来用。单台主机环境下它很常见，十几块盘做个RAID5或者RAID10，然后建一个存储卷，虚拟机就放上面。

本地盘做存储卷最大的优点是性能好、延迟低，因为没有网络开销，SSD的话哪怕SATA接口也能跑出很好的4K随机读性能。缺点也很明显：主机本身就变成了单点。如果这台服务器主板烧了、电源炸了，本地盘上的所有虚拟机全部跟着遭殃。

我见过不少客户一开始嫌共享存储贵，全部用本地盘，结果一年之内两次数据丢失。最典型的一次是RAID卡电池坏了，写缓存策略失效，恰好碰到一次意外断电，整个卷的元数据全部损坏，VMFS结构都检查不出来。

所以本地盘存储卷只建议用于以下场景：单机测试环境、边缘节点、开发环境，或者配合vSAN这类分布式软件将多台本地盘聚合成一个共享池。

2.2 SAN存储卷：虚拟化时代的“标准答案”

SAN（存储区域网络）提供了基于块的存储卷，常见的协议是FC和iSCSI。ESXi主机通过HBA卡或者软件适配器连接存储阵列，由存储侧创建一个LUN（Logical Unit Number，逻辑单元号），主机把它格式化成一个VMFS数据存储。

SAN存储卷有几个关键特征值得注意：

第一个特征是多个主机可以同时访问同一个LUN。这一点是虚拟化集群的基础，vMotion跨主机迁移虚拟机的时候，源主机和目标主机必须能看到同一份数据。第二个特征是存储阵列本身提供冗余，双控制器、多路径、快照、复制能力，这些都是存储卷之上的额外保护。第三个特征是性能可以独立扩展，加盘、加闪存、增加端口带宽都能直接作用于存储卷。

SAN卷适合绝大多数生产环境。不过它的实施和维护有门槛，尤其是FC SAN，需要规划Zoning和LUN Masking，还要理解多路径（MPIO）如何配置。iSCSI相对简单，但性能和可靠性依赖你的网络质量，建议要单独设置VLAN或物理隔离网络，不要和业务流量混跑。

2.3 NAS存储卷：灵活性最高的选择

NAS存储卷走的是文件协议，最主流的是NFS。ESXi原生支持NFS 3和NFS 4.1（4.1这个版本我在后面会重点说一下）。

和SAN卷相比，NAS卷最大的区别在于：存储卷本身是一个文件系统（比如NFS导出的共享目录），ESXi在上面直接创建一个VMFS或者直接使用文件协议存放虚拟机文件（实际上ESXi在NFS上用的还是VMFS文件系统格式化的方式，不过ESXi 6.5以后默认是NFS 4.1 + 完整的VMFS封装）。

NFS存储卷的好处无需规划LUN、无需考虑多路径，IP网络通了就能用。对于分支办公室、中小企业，或者跑在通用服务器上的虚拟化集群，NFS的性价比很高。

NFS的问题也来自它的本质——文件协议需要额外处理锁、缓存一致性。在NFS 3时代，并发访问同一个虚拟磁盘时性能下降明显，也容易遇到元数据操作延迟。有了VAAI（vStorage APIs for Array Integration）之后NFS的性能有所改善，但要达到块存储的稳定表现，还是要看存储阵列本身的执行效率。

2.4 vVol虚拟卷：存储感知虚拟化的终局形态

VMware的Virtual Volumes（vVol）改变了存储卷和虚拟机的对应关系。传统方式是一个LUN里放很多个vmdk文件，存储策略是在LUN层面统一管理的。vVol则把每个虚拟机直接映射到存储阵列上的一个单独卷，也就是说虚拟机的每个虚拟磁盘（甚至每个快照）都是存储阵列上的一个独立对象。

这个模式的好处是存储策略（复制、快照、加密）可以直接按虚拟机级别下发，而不影响同一LUN上其他虚拟机。不过vVol必须依赖存储厂商提供的VASA Provider接入，也就是说你的存储阵列要原生支持vVol，否则玩不起来。

目前HPE、NetApp、Pure Storage等主流厂商都支持vVol，如果存储侧本身就是全闪阵列，vVol能带来非常漂亮的性能压缩和策略管理体验。但如果是老旧的存储阵列，不建议强行上vVol，兼容性和稳定性风险都比较高。

3. VMFS存储卷到底是怎么组织数据的

既然题目挂着“vmware扩展vmfs存储卷”，VMFS就值得单独拿一章来讲。VMFS（Virtual Machine File System）是VMware专为虚拟化而生的集群文件系统，普通文件系统是为单机优化的，但VMFS从出生那刻起就是为多台主机同时读写同一个文件系统而设计的。

3.1 VMFS的版本演进：选错版本等于埋雷

VMFS升级到VMFS 6已经很多年了（ESXi 6.5起默认VMFS 6），但很多老机器上还有VMFS 5的存储卷。这两者的区别不是版本号好看而已，底层变化很大：

• VMFS 5文件块大小为1MB（之前可以选2MB/4MB/8MB等），而VMFS 6引入了64KB的子块（sub-block）概念，小文件占用的空间明显减少。
• VMFS 6支持存储卷容量自动扩展（自动检测并扩展物理存储），对多路径主动优化也更好。
• VMFS 6对SSD有专门优化支持TRIM和UNMAP指令，SSD上的写入和回收性能有显著提升。
• VMFS 5最大单文件2TB（调整过可以更大），VMFS 6最大单文件62TB（大致），大数据量虚拟磁盘没那么容易撞天花板。

所以在规划新环境的时候，尽量一步到位升级到VMFS 6。旧环境升级要注意：VMFS 5可以原地直升VMFS 6，这不是破坏性操作，存储卷数据和虚拟机文件都保留。但升级前依然要打快照和完整备份，毕竟存储操作从来都容不得侥幸。前提是ESXi版本要6.5以上，而老版本主机可以访问VMFS 5但访问不了VMFS 6。

3.2 VMFS数据存储的核心结构：LVM分区体系

如果你用lsblk去看ESXi主机的存储设备，会发现LUN上会有分析过的“分区”，这类分区并不是你定义出来的，而是VMFS在初始化的时候自动创建的一套LVM（Logical Volume Manager）结构。VMFS把物理存储划分成几个主要区域：

第一个区域是文件系统的基本头信息（Super Block、Heartbeat区域等），保存着卷的UUID、版本、状态。第二个区域是文件描述符区，也就是保存目录结构和文件元数据的地方，VMFS里每个文件（比如vmdk）都会有一个对应的File Descriptor（文件描述符）。第三个区域是真正的数据区，存放虚拟机磁盘数据的文件块。

理解这个结构很重要，因为以后做存储卷扩容或者遇到存储卷损坏需要手工修复的时候，你知道底层是LVM分区体系，而不是普通EXT4那种结构，处理思路就会明确很多。

3.3 VMFS存储卷的上限和块逻辑

讲VMFS实现细节之前，先给大家一个直观的上限表，做容量规划时直接参考：

VMFS 6的一个单卷最大容量理论值远超64TB，但不要指望单个存储卷无限扩充。你还需要考虑文件描述符区的大小和实际文件数量。如果虚拟机的数量很多而且很碎，文件描述符区会先耗尽，即使卷剩余空间还有很多，也会出现“无法创建新文件”的异常。

4. 实战：vmware扩展vmfs存储卷的完整流程

好，进入正题。扩展VMFS存储卷，简写就是给数据存储扩容。物理层面的操作根据后端存储类型不同会不一样，但ESXi层面的逻辑是相通的。

4.1 先判断存储卷是否具备扩展条件

做任何扩容前，先确认这几个条件：

1. 后端存储是否还有空闲空间可以划给这台主机。
2. 新的LUN或扩容后的LUN，在ESXi主机上是否已经识别到了新增容量。
3. 当前VMFS存储类型是否允许在线扩展。
4. 主机层面的存储适配器（HBA/网卡）是否工作正常。

检查命令也简单，ESXi主机上跑：

esxcli storage vmfs extent list

也可以直接在vSphere Client里，选中目标数据存储，查看“操作 -> 扩展”按钮是否可用。

4.2 后端存储扩容：三种底层环境下的差异

先说SAN块存储。比如一台HPE存储或者一台DELL存储，划的LUN原本是2TB，你需要在存储侧把它扩到3TB。这一般需要在存储管理界面操作，扩建LUN本身是热操作，LUN上的数据不中断，但建议操作前后都要确认多路径状态正常。

再看NAS存储。NFS存储卷扩容则相对简单，在NAS侧把共享目录的配额调大，或者直接把导出的NFS filesystem扩容，ESXi侧自动发现容量变大即可，不需要重新挂载，不需要扫描。

最后看vSAN场景。vSAN不是传统VMFS卷的概念，是通过“vSAN存储策略”来管理容量的。要让存储卷容量变大，直接给集群加盘或加主机，vSAN会自动将容量更新至存储策略要求的对象上。这个不在VMFS扩展范围之内，但容易混淆，这里单独说明。

4.3 在ESXi侧执行VMFS数据存储扩展

后端调整完成后，ESXi上的存储卷还是旧容量，这时候需要让主机重新扫描存储设备，然后执行扩展。操作路径如下：

第一步，在vSphere Client中选择主机，点击“存储”选项卡，然后选择“重新扫描存储适配器”，或者在存储设备上右键选择“重新扫描”。这一步是必须的，否则主机会看不到存储侧新增加的容量。

第二步，选中目标VMFS数据存储，点击“操作 -> 扩展”。在弹出的界面中，你可以选择将存储卷扩到哪一块物理存储设备上。

注意这里有一种情况：如果存储阵列和之前该LUN是同一个LUN但容量增大了，界面会直接显示容量从2TB变成3TB，选择此项扩展即可。如果是额外划了一个全新的LUN出来，希望把它并入已有数据存储，也可以在扩展界面中将它添加为“扩展区”（Extent）。

第三步，确认扩展后的容量。扩展操作是秒级的，不影响存储卷上的虚拟机运行，完全在线操作。不过但凡涉及LUN和文件系统的操作，我无论如何都建议提前做一次虚拟机快照或者备份，数据无价。

4.4 核心命令：esxcli下的扩展操作

在某些场景下你可能没有图形客户端可访问，ESXi Shell或者SSH里的命令同样可以完成扩展，思路和图形界面完全一样：

# 查看数据存储当前extent esxcli storage vmfs extent list # 获取存储设备信息 esxcli storage core device list # 使用一个新LUN或扩展后的LUN来扩展数据存储（需要先卸载？不需要，VMFS原生支持在线扩展） vmkfstools -Z /vmfs/devices/disks/naa.xxxxxxxx /vmfs/volumes/your_datastore_name

vmkfstools的-Z参数是“扩展到一个新的extent”。-z参数则是“向当前extent追加容量”。两者的区别很重要：

• -z：用于同一个LUN本身容量被扩大后，把新增容量追加到当前数据存储。例如原LUN 2TB扩到了3TB，就用-z。
• -Z：用于把另一个独立的LUN或分区添加为新的扩展区，合并到同一个数据存储。例如新增了一个1TB的LUN，希望并到原2TB的卷里，就用-Z。

我把这两个参数的坑列出来，因为这个很容易搞反：

多个extent会导致一个VMFS卷由多个LUN组成，这本身没问题，但如果其中一个extent损坏，整个存储卷的文件系统都会受影响。所以做过-Z扩展的卷，一定要慎用“移除extent”操作。移除extent会要求数据全部迁移，没有外部迁移工具的时候基本做不到。

4.5 VMFS 6的自动扩展与需要手动干预的情况

VMFS 6本身支持在物理存储扩容后自动扩展VMFS，但只针对“单个LUN自身容量变大”的场景。这类场景在vSphere 6.5之后，如果存储卷是在VMFS 6上，主机会自动感知到新的容量并完成在线扩展，无需手动执行任何操作。

但是自动扩展只适用于存储阵列正确报告LUN容量的情况。如果主机有多路径配置异常，或者存储阵列缓存刷新延迟，也可能遇到扩容后主机仍然只看到旧容量。这种情况下的排查顺序是：

1. 重置存储适配器（重新扫描）。
2. 检查多路径插件（NMP/MPP）状态。
3. 确认存储阵列中的LUN映射（Masking）和Zoning没有变化。
4. 查看主机系统和VMkernel日志（/var/log/vmkernel.log），搜索存储卷的容量变化记录。

5. 存储卷选型与容量规划实战建议

光知道怎么扩展还不够，实际项目里如何选择存储卷类型才是真正考验架构能力的地方。我把几种常见场景的选型建议和理由列出来。

5.1 小规模场景（1~3台宿主主机）：本地盘+外部备份，或NFS

小规模环境（如测试机房、小型工作室虚拟化）的一个典型特点是：预算有限、没有专职存储管理员、但对业务连续性有一定要求。

我的建议是：优先考虑NFS存储卷，配合一台普通的NAS设备。理由是NFS不需要学习FC组网和LUN Masking，只要会配NAS共享目录，就能在ESXi上快速挂载。

如果你完全不想买NAS，纯本地盘也能跑，但你要接受重建成本。这种情况下强烈建议开启vSphere Replication，把虚拟机复制到另一台服务器或者另一个本地盘组上，遇到单机故障至少能缩短恢复时间。

本地盘+没有冗余、没有备份，这是运维大忌讳。踩过坑的人都懂。

5.2 中大规模场景（4台以上宿主主机）：FC SAN或iSCSI SAN是底线

一旦ESXi主机数量超过4台，并且虚拟机数量上到50台以上，本地盘的局限性会彻底爆发。这时候共享存储几乎是必须的。预算充足的项目可以选FC SAN（光纤通道），在延迟和稳定性上表现确实好，所有生产环境标准做法都是FC SAN。

预算有限的项目建议选iSCSI。不过iSCSI要出效果，网络设计必须到位：

• 至少使用双千兆（生产环境建议双万兆），分别接到不同的交换机。
• iSCSI网络独立VLAN，不跑业务流量。
• 开启巨帧（MTU 9000）之前先确认交换机端口和存储端口都支持，否则宁可不做。
• 配置多路径（ESXi自带的MCA/固定路径都可以），这样可以避免单链路故障导致的IO中断。

我最初给一家子公司搭的iSCSI环境用的是普通千兆链路，带宽成了瓶颈，虚机迁移慢到怀疑人生。后来换成双万兆之后，一切顺畅，虚拟机存储迁移从原来的几个小时降到十几分钟。

5.3 高性能场景（数据库、高IO应用）：全闪阵列+vVol或纯NVMe本地盘

如果虚拟机里跑的是数据库、ERP、报表分析，存储重点考虑随机IOPS和延迟。这时候有两套主流方案：

方案一是全闪存储阵列+vVol。卷策略直接按虚拟机下发，快照、克隆、加密都走阵列级功能，IO路径最短，延迟通常在0.5ms以内。vVol对数据库类虚拟机尤其友好，因为每个虚拟机数据卷都是独立的，互不干扰。

方案二是vSAN全闪配置，把每台宿主机的NVMe SSD组建成一个分布式存储池。vSAN在IO路径上需要经过VMkernel的网络栈，延迟比纯SAN略高，但胜在无硬件阵列的单点故障，扩容也容易。

具体选哪套取决于你现有硬件生态。已经在用某一厂家的服务器和存储，延续同品牌生态，在运维成本上会更低。

5.4 容量规划时最容易忽略的三个隐藏成本

第一，快照占用。每做一个虚拟机快照，存储卷就会增加一份差异数据。当快照数量较多且时间较长时，存储卷容量可能突然被耗尽。所以如果项目里经常打快照，预留容量建议在正常使用量的基础上再增加20%-30%。

第二，性能与容量分开考虑。一个存储卷剩余空间充裕，不代表它能扛住高IO压力。有时候VM卡顿不是空间不够，而是底层物理盘性能不足。容量规划时一定要同时考虑IOPS，而不是只看容量数字。

第三，文件数量上限。我前面提到过，VMFS卷文件描述符区有上限（VMFS 6大约每卷130,000个文件）。看这个数字觉得很多，但单台虚拟机的快照、日志文件、交换文件一多，规模大了之后文件数会快速膨胀。如果接近上限，存储卷会报告“空间不足”但实际磁盘还有大量剩余空间。

6. 存储卷管理避坑指南：日常维护与排错实录

最后分享一批我实际工作中踩过的坑，和对应的排查办法。这部分内容常规文档里不会写，但极其影响日常运维幸福感。

6.1 存储卷显示“不活动”或“无法访问”

有一次客户报障说ESXi主机上的数据存储在界面里变成灰色，状态为“不活动”。我第一时间检查存储侧，发现存储阵列的控制器已经重启过了，但LUN映射列表发生变化。排查步骤：

1. 先看主机存储适配器状态，确认物理链路正常。
2. 在存储侧检查LUN是否正常处于映射和屏蔽状态，是否意外被取消映射。
3. vCenter里的数据存储右键选择“挂载”或“卸载”后重新挂载。

多路径配置出错也会导致类似现象。检查命令：

esxcli storage nmp path list

如果发现所有路径都显示Dead，那多半是链路或存储侧屏蔽有问题，要逐段排查。

6.2 VMFS存储卷扩容后虚拟机无法写入

这是一个比较隐蔽的问题。某客户把一个LUN从1TB扩到2TB，VMFS卷显示扩容成功，但虚拟机写数据到某个vmdk时报“磁盘空间不足”。

排查后发现了根因：原存储卷中某个vmdk的单文件大小超过了VMFS 5的2TB限制，扩容后的总容量是变大了，但单个虚拟磁盘文件因为格式限制无法继续增大。

解决办法是把虚拟磁盘格式从thin转换为thick，或者更推荐直接新建一个更大的VMDK，迁走数据后切换。确认现有VMFS版本，生产环境尽快规划升级到VMFS 6。

6.3 存储卷大量空间被占用但又找不到文件

这类问题常出现在频繁使用快照或删除虚拟机后。实际原因通常是vmdk的“虚拟大小”大于“占用大小”，删除文件后VMFS不会马上把空间返回给存储卷。VMFS 6可以利用UNMAP回收未使用空间：

在ESXi主机上执行：

esxcli storage vmfs unmap -l datastore_name

如果是VMFS 5，你可能需要先升级到VMFS 6才能享受自动回收功能，或者定期执行UNMAP操作。

注意，UNMAP操作也会占用存储I/O资源，建议在业务低谷期执行，不要在高峰期频繁触发。

6.4 通过命令行快速查看存储卷健康状态

日常巡检我建议养成用命令行查看存储卷的习惯，速度快、信息全。常用命令总结：

# 查看所有存储卷基本信息 esxcli storage vmfs list # 查看VMFS卷的extent组成 esxcli storage vmfs extent list # 查看存储设备基本信息（NAA标识、容量、状态） esxcli storage core device list # 查看存储卷无用的快照占用 vim-cmd vmsvc/snapshot.getallvms

其中esxcli storage core device list的输出里，naa开头的设备号就是LUN的唯一标识，你在存储侧做LUN映射时一定要确保ESXi看到的NAA和存储侧呈现的一致，否则容易映射错设备。

6.5 在线扩展时最容易被忽视的“时间窗”风险

所有存储卷操作都有一个隐形的安全时间窗——就是你在存储阵列调整容量、但还没让ESXi重新扫描中间的间隔。这个期间虚拟机还在正常读写，存储阵列端如果正在执行LUN重建、重映射或者缓存回写，可能导致ESXi端I/O挂起。

所以规范操作顺序是：先暂停业务写入（可选）、调整存储阵列容量、完成LUN重映射检查、再执行ESXi重新扫描、最后扩展VMFS。如果业务完全不能中断，至少也要在变更窗口内操作，并且全程盯着vCenter里的任务和告警。

实际项目里我还习惯在操作前把ESXi的配置备份一份：

vim-cmd hostsvc/firmware/sync_config

这样即使操作过程中出了意外，也可以快速恢复主机配置。

7. 一个vSAN扩展存储卷的真实案例复盘

分享一个上个月处理的vSAN存储卷容量扩展案例，整个过程中踩了一个比较典型的坑，复盘出来给大家做参考。

客户环境是6节点vSAN集群，全部NVMe盘，总可用容量大约40TB。某天告警提示存储卷容量超过85%，需要扩容。一般的做法是给集群添加新的容量盘即可，最简单的操作是将vSAN存储策略的“容错方法”从“RAID-1（镜像）”改为“RAID-5”或者“RAID-6”，来降低冗余开销并释放容量。但客户没有冗余欠账空间，因此还是走了加盘路线。

新加了两块NVMe盘之后，vSAN集群显示系统容量确实增加了，但VM存储策略里的“对象空间”仍没有变化，甚至有部分对象报“合规性不满足”。

排查后才发现：新加的盘虽然被vSAN认到了，但默认存储策略要求的所有对象仍然放置在没有故障的旧设备上，vSAN不会自动重平衡数据。解决方式是手动触发重平衡：

1. 检查vSAN健康状态，确认无异常。
2. 在vSAN管理界面中，将存储策略临时调整为“允许重平衡”，或者手动触发重平衡任务。
3. 等待数据迁移完成。

这个案例说明，存储卷扩容到末端不只是“加设备”那么简单，还要了解上层存储策略和对象布局的关联，否则存储卷扩展了，虚拟机却还是访问不到新空间。

如果你是做虚拟化的，建议每半年就重新审视一次存储卷的容量、性能、冗余现状，不要等到告警再动。存储卷管理从来不是一个静态的规划任务，而是一个持续演进的过程。

我在最开始入行的时候也犯过低级错误，比如直接在存储阵列上删除了一个卷，结果发现它还被ESXi主机用着，好在当时环境是测试环境。从那以后再也没敢在没确认存储卷关联的情况下动手。做存储操作，一句话：多看、多查、多想，动设备之前把链路、映射、关联关系全确认一遍再下手。