VMware vSphere 共享 VMFS 数据存储安全卸载与 LUN 分离流程

在 vSphere 集群中下线共享 VMFS 数据存储，不能直接从存储阵列删除或取消映射 LUN。正确顺序是先清理业务和系统引用，再从所有 ESXi 主机卸载数据存储、分离后端设备，最后才在阵列侧取消映射并重新扫描。

本文整理一次共享 VMFS 数据存储下线的完整过程。现场截图包含主机地址、数据存储 UUID 和设备 WWN 等信息，因此不在文章中展示；命令中的名称、UUID、naa 设备号和主机范围均使用可替换参数。

适用范围

本文适用于以下场景：

FC 或 iSCSI LUN 上创建的共享 VMFS 数据存储。
数据存储已经完成业务迁移，准备从一个或多个 ESXi 集群永久下线。
可以同时检查 vCenter、全部 ESXi 主机和存储阵列映射关系。

本文不适用于 NFS、vVol、vSAN，也不适用于正在发生 APD、PDL 或存储链路故障的场景。故障状态下应先恢复或确认存储可用性，不能直接套用计划下线流程。

先区分四个操作

数据存储下线过程中，以下操作含义不同：

操作	作用	是否影响后端数据
卸载 Datastore	让 ESXi 不再挂载 VMFS 文件系统	不删除 VMFS 数据
分离设备	让指定 ESXi 停止使用对应 `naa.*` 设备	不删除阵列上的 LUN
取消 LUN 映射	存储阵列不再向 ESXi 主机组呈现 LUN	通常不删除卷数据
删除数据存储或后端卷	删除 VMFS 或阵列卷	可能永久破坏数据

如果目标只是暂时退出当前集群并保留卷，做到卸载、分离和取消映射即可。不要为了让 vCenter 中的名称消失而直接点击“删除数据存储”。

正确的整体顺序

确认对象和影响范围
  -> 迁移业务并清理引用
  -> 所有 ESXi 卸载 Datastore
  -> 所有 ESXi 分离 naa 设备
  -> 存储阵列取消 LUN 映射
  -> 所有 ESXi 重新扫描
  -> 验证 vCenter、设备和路径状态

阵列取消映射必须晚于所有主机完成分离。否则 ESXi 可能进入 APD 或 PDL 状态，影响主机存储栈和其他业务。

一、记录数据存储与 LUN 对应关系

先登录任意仍能看到目标存储的 ESXi 主机，查看当前文件系统：

# 列出数据存储名称、VMFS UUID 和挂载状态
esxcli storage filesystem list

正确命令空间是 storage filesystem list，不是 storage vmfs filesystem list。

再查询 VMFS 与后端设备的对应关系：

# 列出每个 VMFS 数据存储对应的 naa 设备和分区号
esxcli storage vmfs extent list

操作前至少记录以下信息：

项目	用途
Datastore 名称	在 vCenter 中确认业务和主机范围
VMFS UUID	精确执行卸载和文件占用检查
`naa.*` 设备号	精确执行设备级检查和分离
Extent Number	判断是否为多 Extent 数据存储
Partition	核对 VMFS 所在分区
LUN 容量和阵列 LUN ID	避免同容量 LUN 选错对象
可见该 LUN 的主机清单	确保每台主机都完成卸载和分离

如果一个 VMFS 包含多个 Extent，需要记录并处理全部 naa.* 设备，不能只处理 Extent 0。

二、清理数据存储引用

数据存储浏览器显示为空，不代表它已经没有引用。卸载前应在 vCenter 中确认：

没有虚拟机、模板或 vCLS 虚拟机注册在目标数据存储上。
没有 VMDK、快照、ISO、软盘映像、.vswp、.vmem 或 .vmss 位于目标卷。
没有备份、恢复、克隆、复制或 Storage vMotion 任务正在运行。
数据存储不再属于需要自动调度的 Datastore Cluster。
没有被 Storage I/O Control 使用。
没有被选为 HA Datastore Heartbeat。

还应逐台检查 ESXi 的系统级引用，包括：

Scratch
Syslog
Core Dump
ProductLocker
Host Cache
主机或虚拟机交换文件位置

这些配置如果指向目标数据存储，需要先迁移到其他有效位置。Scratch、ProductLocker 等引用在部分版本中可能需要维护窗口和主机重启才能完全释放。

三、检查文件级占用

在仍挂载目标数据存储的每台 ESXi 上执行：

# 避免当前 SSH 会话的工作目录位于目标数据存储
cd /

# 按实际环境替换数据存储名称和 VMFS UUID
DS_NAME='<DATASTORE_NAME>'
DS_UUID='<VMFS_UUID>'

# 同时按名称和 UUID 检查打开文件
lsof | grep -E "$DS_NAME|$DS_UUID"

如果没有输出，表示 lsof 没有发现该主机上打开的目标卷文件，但这不等于整个集群已经完成清理。其他主机以及 HA、Scratch、Syslog 等配置引用仍需分别确认。

如果有输出，应根据最后一列的文件路径处理：

路径特征	常见原因	正确处理方式
`.iso`	虚拟机光驱仍挂载 ISO	在虚拟机设置中断开并取消“启动时连接”
`.vmdk`、`-flat.vmdk`	虚拟磁盘仍在使用	Storage vMotion 或正常停机迁移
`-delta.vmdk`、`-sesparse.vmdk`	快照或磁盘整合未完成	删除快照并完成磁盘整合
`.vmx`	虚拟机配置仍位于目标卷	迁移或正常注销虚拟机
`.vswp`	虚拟机交换文件仍在目标卷	迁移、关闭虚拟机或调整 Swap 位置
`.locker-*`	ESXi Scratch 指向目标卷	修改 Scratch 位置并按需重启主机
日志文件	Syslog 指向目标卷	修改日志目录后重新加载 Syslog
`.vSphere-HA`	HA 仍在使用该数据存储	更换 HA 心跳数据存储并等待重新配置

不要直接删除这些文件，也不要因为看到进程名就执行 kill -9。

四、从所有 ESXi 卸载数据存储

优先从 vCenter 的数据存储卸载向导操作，并选择所有仍显示“已挂载”的 ESXi 主机。也可以在单台失败主机上使用 CLI 精确验证：

# 使用实际 VMFS UUID，避免数据存储重名
DS_UUID='<VMFS_UUID>'

# 卸载 VMFS 文件系统
esxcli storage filesystem unmount -u "$DS_UUID"

# 验证挂载状态
esxcli storage filesystem list | grep "$DS_UUID"

卸载成功后可能有两种表现：

目标 UUID 不再出现在 filesystem list 中。
目标卷仍显示，但 Mounted 为 false，类型显示为 VMFS-unknown version。

第二种表现是旧版 ESXi 在 VMFS 卸载后的常见显示状态，不代表文件系统已经损坏。

对多个数据存储操作时，应一次处理一个卷。每个卷确认卸载成功后，再继续下一个；某个卷出现 busy、resource in use 或其他错误时，应先停止并定位原因。

五、理解 `lsof` 与设备 World 的区别

lsof 和 device world list 检查的层次不同：

命令	检查层次	主要用途
`lsof`	VMFS 文件系统层	查找打开的 VMDK、ISO、Swap、日志等文件
`storage core device world list`	SCSI 设备层	查看哪些 VMkernel World 仍打开整个 LUN

数据存储仍处于挂载状态时，设备 World 检查可能出现大量 hostd-worker、vpxa-worker、storageRM、helper 等系统 World。这通常是挂载状态下的正常现象，不能直接认定为异常占用，更不能据此杀进程。

正确做法是在数据存储卸载成功后，再执行设备级检查：

# 使用 vmfs extent list 查到的实际 naa 设备号
DEVICE_ID='naa.<LUN_WWN>'

esxcli storage core device world list -d "$DEVICE_ID"

如果卸载后仍有输出，应暂停分离并确认 World 的实际来源；如果没有输出，再进入设备分离。

六、在所有主机上分离 LUN

设备分离按“一个 LUN 完成全部主机，再处理下一个 LUN”的顺序执行，便于核对和回退。

# 使用当前 LUN 的实际 naa 设备号
DEVICE_ID='naa.<LUN_WWN>'

# 将设备置为 off，即从当前 ESXi 分离
esxcli storage core device set -d "$DEVICE_ID" --state=off

# 检查设备状态
esxcli storage core device list -d "$DEVICE_ID"

验证结果应包含：

Status: off

这一步必须在所有能够看到该 LUN 的 ESXi 主机上执行，不只是最后一台显示“已挂载”的主机。完成后应形成主机与 LUN 的核对表，确认每个组合都已经是 Status: off。

七、在存储阵列取消映射

只有满足以下条件后，才能修改阵列映射：

所有 ESXi 对目标 Datastore 均显示已卸载。
所有 ESXi 上对应 naa.* 设备均为 Status: off。
没有其他集群、物理服务器、备份平台或灾备系统使用这些 LUN。
已核对 WWN、容量、阵列 LUN ID 和业务归属。

然后从存储阵列的 ESXi Host Group 或 Initiator Group 中取消 LUN 映射。如果需要保留数据，只取消映射，不要删除后端卷。

八、取消映射后重新扫描

重新扫描应放在阵列取消映射之后。如果 LUN 仍然映射给 ESXi，提前扫描不会让它真正消失，设备通常仍会作为已分离对象存在。

在所有相关 ESXi 上执行：

# 阵列取消映射后，扫描全部存储适配器
esxcli storage core adapter rescan --all

使用实际设备号验证设备和路径已经消失：

DEVICE_ID='naa.<LUN_WWN>'

# 正常情况下应查不到目标设备
esxcli storage core device list | grep "$DEVICE_ID"

# 正常情况下也应查不到目标路径
esxcli storage core path list | grep "$DEVICE_ID"

两条命令均无输出，说明该 LUN 已经不再由当前 ESXi 发现。

九、vCenter 中仍显示“非活动”怎么办

ESXi 卸载完成后，vCenter 中的数据存储可能不会立即消失，而是先显示为“非活动”。这是因为 vCenter 清单对象和主机实时挂载状态不是同一个层次。

完成全部主机分离、阵列取消映射和存储适配器重新扫描后，再刷新 vCenter。只要没有 ESXi 继续报告这个 VMFS，对应数据存储通常会从清单中消失；旧版 vCenter 可能需要等待状态同步。

不要为了清理“非活动”名称而直接选择“删除数据存储”。如果完成标准流程后仍长期残留，应单独检查 vCenter 清单引用，而不是破坏仍需保留的 VMFS。

十、回退方法

如果设备已分离，但阵列尚未取消映射，可以在确认业务允许后重新启用设备：

DEVICE_ID='naa.<LUN_WWN>'
DS_UUID='<VMFS_UUID>'

# 重新启用设备
esxcli storage core device set -d "$DEVICE_ID" --state=on

# 扫描存储适配器
esxcli storage core adapter rescan --all

# 按 UUID 重新挂载 VMFS
esxcli storage filesystem mount -u "$DS_UUID"

如果阵列已经取消映射，需要先在阵列恢复原 Host Group 映射，再按“重新扫描、启用设备、挂载 VMFS”的顺序恢复。恢复时仍要核对原 LUN WWN，不能把同容量的新 LUN 当作原设备。

最终检查清单

计划下线共享 VMFS 时，最重要的不是某一条命令，而是严格保持顺序：先清理引用，再卸载文件系统；先从全部主机分离设备，再从阵列取消映射；最后才重新扫描和清理 vCenter 显示。这个顺序可以最大限度避免 APD、PDL 和误删数据。