ESXi 存储路径丢失（PDL/APD）完整处置教程：分清类型再操作，一步不踩坑

本文针对 VMware ESXi 虚拟化环境中高发的存储路径丢失故障，详解 PDL（永久设备丢失）与 APD（全路径中断）两类故障的核心区别、精准识别方法，明确官方标准处置流程，拆解 PDL 安全迁移虚拟机、APD 静默等待自动恢复的核心原则，同时梳理运维高频踩坑红线与事前预防方案，帮助管理员快速合规处置故障，避免误操作导致业务中断或数据丢失。

在 VMware vSphere 虚拟化架构中，存储是整个平台的命脉，90% 以上的严重业务中断故障，都和存储链路异常相关。其中 PDL 与 APD 是 ESXi 环境中最常见的两类存储路径丢失故障，二者的触发场景、底层机制完全不同，对应的处置原则更是天差地别。很多运维人员遇到故障时慌不择路，混淆两类故障的处理方式，反而导致原本可以自动恢复的业务彻底中断，甚至引发数据丢失。本文将从底层逻辑到实操流程，带大家全面掌握 PDL/APD 故障的全流程处置方法。

一、先搞懂核心：PDL 与 APD 到底有什么区别？

处置故障的前提，是精准区分故障类型。PDL 和 APD 虽然都表现为 “存储路径丢失、ESXi 主机无法访问 LUN”，但二者的本质、ESXi 的底层行为、处置原则完全不同，我们先通过一张表把核心差异讲透：

表格

简单来说：PDL 是 “存储设备真的没了，再也回不来了”，必须主动处置；APD 是 “存储链路临时断了，大概率能自己恢复”，乱操作反而会搞崩业务。

二、故障第一步：精准识别 PDL 与 APD，避免处置方向错误

遇到存储路径异常告警，绝对不能上来就操作虚拟机，第一步必须 100% 确认故障类型，这是整个处置流程的核心前提。下面给大家提供两种最精准、最常用的识别方法，适配 vCenter 可访问和断连两种场景。

2.1 图形化界面识别（vCenter/vSphere Client 可正常访问）

1. 告警与事件识别
   • PDL 故障：vCenter 会触发明确的永久设备丢失告警，事件日志中会标注 “Device naa.xxxx has entered permanent device loss state”，故障 LUN 的状态会变为 “不活动 / 已脱机”，且标注永久不可用；
   • APD 故障：vCenter 会触发所有路径 down告警，事件日志中会标注 “Device naa.xxxx has entered all paths down state”，故障 LUN 的状态为 “降级 / 脱机”，但无 “永久丢失” 相关标注。
2. 存储清单验证进入 vCenter「存储」视图，找到故障 LUN，查看其设备状态与路径信息：PDL 故障的 LUN 所有路径均为失效，且设备状态标注永久丢失；APD 故障的 LUN 所有路径均为 down，但设备仍处于待重试连接状态。

2.2 命令行识别（vCenter 断连、仅能访问 ESXi 主机 Shell）

当 vCenter 因存储故障无法访问时，可直接登录 ESXi 主机的 Shell 终端，通过以下命令精准识别故障类型，这也是 VMware 官方认定的最权威识别方式。

1. 查看存储设备全局状态，确认故障类型

   esxcli storage core device list

   • 若为 PDL 故障：目标设备的Status字段会明确标注PDL，同时设备的Is Permanent Device Loss字段为true；
   • 若为 APD 故障：目标设备的Status字段为Offline，无 PDL 相关标注，Path State字段会显示所有路径均为down，但设备仍处于重试连接状态。

2. 通过内核日志确认故障类型（最精准）ESXi 的所有存储事件都会记录在 vmkernel 内核日志中，执行以下命令可直接过滤出故障相关的精准日志：

   # 过滤PDL相关日志 tail -f /var/log/vmkernel.log | grep "permanent device loss" # 过滤APD相关日志 tail -f /var/log/vmkernel.log | grep "all paths down"

   日志中出现明确的permanent device loss state，即可 100% 确认为 PDL 故障；出现all paths down state，则确认为 APD 故障。

三、标准处置流程：严格遵循核心原则，零踩坑处理故障

3.1 PDL 故障处置全流程：核心是安全迁移虚拟机，彻底下线故障设备

PDL 故障的本质是存储设备永久不可恢复，不存在 “等待链路恢复” 的可能，拖延处置只会导致运行在故障 LUN 上的虚拟机因 I/O 失败彻底崩溃，因此核心处置原则是快速、安全地将所有关联虚拟机迁移出故障 LUN。

步骤 1：故障范围锁定，无遗漏梳理关联虚拟机

处置前必须先完成全面梳理，避免遗漏关联虚拟机导致二次故障：

1. 确认所有进入 PDL 状态的 LUN 清单，记录对应的设备 ID（naa.xxxx）；
2. 梳理所有关联的虚拟机，包括：系统盘 / 数据盘在故障 LUN 上的虚拟机、快照文件 / 交换文件存放在故障 LUN 上的虚拟机、CDROM 挂载了故障 LUN 内镜像的虚拟机；
3. 对虚拟机进行业务优先级分级，优先处置核心业务虚拟机，保障核心业务可用性。

步骤 2：分场景安全迁移虚拟机，核心操作红线不能碰

根据虚拟机的运行状态，采用对应的合规迁移方式，严禁违规操作导致虚拟机崩溃：

• 场景 1：虚拟机仍处于运行状态，业务未完全中断

  1. 立即暂停该虚拟机的所有写密集型业务，避免客户机操作系统因持续 I/O 错误触发内核崩溃；
  2. 优先执行冷迁移：先通过客户机操作系统执行正常关机（若无法正常关机，可执行强制关机，严禁直接在 ESXi 层面硬断电），关机完成后，将虚拟机的完整文件（配置文件、磁盘文件、快照文件）全部迁移至正常的共享存储 LUN；
  3. 若核心业务不允许停机，可先执行纯计算 vMotion 迁移，仅将虚拟机的运行实例迁移至集群内负载正常的 ESXi 主机，暂时保留业务运行，待业务低峰期立即完成冷迁移，彻底脱离故障 LUN；
  4. 绝对禁止操作：严禁对 PDL LUN 上的运行中虚拟机执行 Storage vMotion 热存储迁移，此时源 LUN 已无法正常读取数据，会直接导致迁移失败、虚拟机崩溃。

• 场景 2：虚拟机已处于挂起、异常关机或无法启动状态

  1. 直接执行冷迁移，将虚拟机的完整文件迁移至正常存储卷，迁移完成后重新开机验证业务；
  2. 若迁移过程中提示磁盘文件无法读取，说明故障 LUN 已无法读取数据，立即停止迁移操作，从备份系统恢复该虚拟机的完整数据至正常存储，重新注册虚拟机后启动业务。

步骤 3：故障收尾与环境清理，避免残留配置引发后续故障

1. 所有虚拟机迁移完成后，在 vCenter 中卸载并移除所有 PDL 状态的故障 LUN，解除存储设备与 ESXi 主机的映射关系；
2. 在集群内所有 ESXi 主机上执行存储重新扫描，清除 PDL 设备的残留配置信息，避免后续存储配置冲突；
3. 完成根因排查与修复：确认 PDL 故障是存储端误操作、硬件故障还是配置错误导致，完成修复后制定对应的变更规范，避免同类故障复发。

3.2 APD 故障处置全流程：核心是静默等待链路恢复，期间严禁操作虚拟机

APD 故障的本质是临时链路中断，ESXi 会持续重试连接存储路径，只要链路恢复，虚拟机的 I/O 会自动恢复，业务无感知。绝大多数 APD 故障的业务中断，都是运维人员在故障期间乱操作导致的，因此核心处置原则是优先排查修复链路，期间绝对不要对受影响的虚拟机执行任何操作。

阶段 1：故障确认与影响评估（故障发生 0-5 分钟）

1. 100% 确认故障类型为 APD，排除 PDL 故障，绝对不能混淆处置原则；
2. 确认故障影响范围：是单台 ESXi 主机的路径故障，还是整个集群的全路径故障；是单 LUN 异常，还是整个存储阵列的链路中断；
3. 梳理受影响的虚拟机清单，重点标记核心业务虚拟机，此时无论虚拟机是否出现 I/O 卡顿，都不要执行任何开机、关机、重启、迁移操作，哪怕是业务出现临时中断，也不要贸然操作。

阶段 2：核心处置：排查根因修复链路，等待自动恢复

APD 故障处置的核心工作，不是操作虚拟机，而是尽快排查并修复存储链路故障，链路恢复后，业务会自动恢复，无需任何人工干预。常见的根因排查方向，按优先级排序：

1. SAN 网络侧：检查光纤交换机端口状态、zone 配置是否被误修改、光纤线是否松动 / 损坏、交换机 ISL 链路是否正常；
2. 存储阵列侧：检查存储控制器是否处于重启 / 升级状态、前端端口是否 down、LUN 映射配置是否变更、缓存是否降级；
3. ESXi 主机侧：检查 HBA 卡状态、驱动与固件版本是否兼容、存储多路径配置是否正常。

链路修复后，ESXi 主机会在 30 秒内自动检测到路径恢复，自动退出 APD 状态，虚拟机的 I/O 会自动恢复正常，业务会无感知恢复。若链路修复后主机未自动识别，可手动执行存储重新扫描命令触发识别，仅此操作即可，不要执行其他操作：

# 重新扫描所有存储适配器 esxcli storage core adapter rescan --all

阶段 3：极端场景处置：链路长时间无法恢复的合规操作

只有当确认存储链路短时间内无法恢复（比如存储阵列硬件故障，需要数小时甚至更久修复），且核心业务必须紧急恢复时，才能执行人工处置，且必须严格遵循以下步骤：

1. 先确认受影响的虚拟机有完整的可用备份，避免数据丢失；
2. 对受影响的虚拟机执行强制关机，不要尝试重启或挂起操作；
3. 从备份系统将虚拟机的完整数据恢复至正常的存储卷，重新注册并启动虚拟机，恢复业务；
4. 严禁在链路未恢复的情况下，对运行中的虚拟机执行任何迁移、重启操作，会直接导致虚拟机崩溃且无法恢复。

阶段 4：故障恢复后的验证与收尾

1. 链路恢复后，确认所有存储路径均处于正常活动状态，LUN 状态恢复正常，无残留异常告警；
2. 逐台验证受影响的虚拟机，确认业务运行稳定，I/O 读写正常，无数据丢失或文件系统损坏；
3. 复盘故障根因，优化存储链路冗余配置，避免同类故障再次发生。

四、绝对不能碰的运维踩坑红线

根据 VMware 全球技术支持中心的故障统计，80% 以上的 PDL/APD 故障扩大，都是因为运维人员违反了核心处置原则，触碰了以下操作红线，大家一定要严格规避：

1. 红线 1：混淆 PDL 与 APD 的处置原则。APD 故障时贸然迁移、重启虚拟机，导致原本可自动恢复的业务彻底中断；PDL 故障时傻等链路恢复，错过最佳迁移时机，导致虚拟机批量崩溃。
2. 红线 2：APD 故障期间操作虚拟机。故障期间对受影响的虚拟机执行开机、关机、重启、迁移操作，是最高发的踩坑行为，会直接导致虚拟机配置文件损坏、文件系统不一致，链路恢复后也无法正常启动。
3. 红线 3：PDL 故障时强行操作故障 LUN。对 PDL 状态的 LUN 反复执行重新扫描、强制挂载操作，会导致 ESXi 主机的管理代理卡死，甚至触发主机 PSOD 紫屏，导致整个集群的业务中断。
4. 红线 4：故障发生后贸然重启 ESXi 主机。重启主机不仅无法解决存储链路问题，还会导致该主机上所有运行的虚拟机全部中断，大幅扩大故障影响范围。
5. 红线 5：随意修改 ESXi 的 APD/PDL 高级参数。未经测试就修改 APD 超时时间、PDL 自动移除等核心参数，会导致临时链路闪断就触发虚拟机强制关机，反而大幅增加业务中断风险。

五、事前预防：PDL/APD 故障的前置优化最佳实践

最好的故障处置，是提前规避故障发生。结合 VMware 官方最佳实践，给大家整理了 5 项核心优化措施，可大幅降低 PDL/APD 故障的发生概率，提升平台容错能力：

1. 完善存储链路冗余配置。每台 ESXi 主机配置双 HBA 卡、双光纤交换机、双存储控制器，多路径策略配置为 RR（循环）模式，避免单节点、单链路故障导致全路径中断。
2. 规范存储变更流程。所有存储端的 LUN 删除、映射变更、控制器重启操作，必须提前在 vCenter 中完成 LUN 卸载、虚拟机迁移，严禁直接在存储端执行变更操作，避免触发 PDL/APD 故障。
3. 优化 ESXi 核心参数配置。根据业务场景，基于官方规范调整高级参数：开启Disk.AutoremoveOnPDL（PDL 磁盘自动移除）、启用Misc.APDHandlingEnable（APD 自动处理机制），调整适配业务的Misc.APDTimeout超时参数。
4. 配置全链路监控告警。在 vCenter 中配置 PDL/APD 实时告警，同时对光纤交换机端口、存储控制器状态、ESXi 存储路径状态配置监控，提前发现链路隐患，在故障发生前完成处置。
5. 完善备份容灾体系。所有核心业务虚拟机必须配置定时全量 + 增量备份，核心存储配置同城容灾方案，确保极端 PDL 故障场景下，可快速恢复业务，避免数据永久丢失。

总结

ESXi 存储路径丢失故障的处置，核心前提永远是先精准区分 PDL 与 APD，再执行对应操作。PDL 故障的核心是主动出击，快速安全地将虚拟机迁移出永久失效的存储设备；APD 故障的核心是静默等待，优先修复链路，期间绝对不要操作虚拟机。

只有严格遵循 VMware 官方的标准处置流程，坚守操作红线，才能最大程度保障业务连续性，避免误操作导致的故障扩大和数据丢失，守护好虚拟化平台的存储生命线。