Windows iSCSI连接后磁盘未显示在“磁盘管理”中？

Question

Windows iSCSI连接成功后，目标磁盘在“磁盘管理”中完全不显示（既无“未初始化”提示，也无灰色磁盘条目），是典型但易被忽视的集成问题。常见原因包括：iSCSI启动器未以管理员权限运行导致WMI或存储服务通信异常；目标LUN未正确映射至该发起程序IQN（尤其在多主机共享存储场景中）；Windows存储服务（StorSvc）、iSCSI Initiator Service 或 VDS（Volume Shadow Copy）服务未运行或处于延迟启动状态；防火墙或网络策略拦截了SCSI-3 PR（Persistent Reservation）或MSFT_Volume类WMI查询流量；此外，某些存储阵列（如群晖、TrueNAS）需手动启用“允许非管理员访问”或禁用“CHAP强制认证”才能触发磁盘枚举。注意：即使iscsicli list targets返回正常，也不代表LUN已对OS可见——本质是VDS提供者未能从iSCSI堆栈获取设备PDO。建议优先通过diskpart执行`rescan`并检查`list disk`输出，再结合事件查看器中“Microsoft-Windows-Storage-Management/Operational”日志定位根本原因。

Answer 1

```html

一、现象层：磁盘管理器“彻底失联”——无条目、无提示、无响应

当Windows iSCSI发起端成功登录目标（iscsicli list targets 显示Target Name且状态为Active），但“磁盘管理”中既无灰色未初始化磁盘，也无任何LUN占位符，甚至diskpart → list disk亦为空——这并非连接失败，而是存储子系统在设备枚举环节发生静默中断。该现象区别于“离线/只读/需初始化”等可见状态，属典型的PDO（Physical Device Object）未注入VDS Provider层级故障。

二、服务层：核心存储服务链的隐性断裂

• StorSvc（Storage Service）：Windows 10/Server 2016+中替代旧版Disk Management服务的核心组件，负责向VDS暴露MSFT_Volume、MSFT_Disk等WMI类；若其处于Disabled或Delayed Auto但尚未触发启动，则WMI查询直接返回空集。
• iSCSI Initiator Service：虽不影响登录，但控制SCSI总线扫描与设备报告路径；设为手动时，rescan可能不触发底层PnP通知。
• VSS（Volume Shadow Copy）与 VDS（Virtual Disk Service）：二者协同构建存储管理视图；禁用VSS将导致VDS Provider无法注册，表现为Get-WmiObject -Namespace root\wmi -Class MSFT_Volume无输出。

三、权限与上下文层：被低估的UAC与会话隔离

iSCSI Initiator UI若未以管理员权限运行，其调用的WMI操作（如MSFT_iSCSITargetPortal枚举）将受限于会话0隔离与COM权限策略，导致StorSvc接收不到完整设备拓扑变更事件。验证方式：
runas /user:Administrator "mmc diskmgmt.msc" 后立即执行rescan——常可瞬时显现磁盘。

四、网络与协议层：防火墙与SCSI语义级拦截

拦截点	协议/端口	影响机制	检测命令
Windows Defender 防火墙	TCP 3260 + ICMP + WMI over DCOM	阻断MSFT_Volume类WMI查询响应，VDS无法构建卷视图	netsh advfirewall firewall show rule name="iSCSI"
存储阵列ACL	SCSI-3 PR (Persistent Reservation) 流量	TrueNAS/Synology默认拒绝非PR-capable主机的LUN枚举请求	iscsicli ReportTargetPortals 对比Portal IP是否匹配阵列允许列表

五、存储阵列侧配置层：厂商特异性“开关”

群晖DSM需启用“iSCSI LUN 允许非管理员访问”（位于LUN属性→高级设置）；TrueNAS SCALE要求禁用“强制CHAP认证”（即使发起端未配CHAP），否则LUN仅对已认证IQN可见——但Windows StorSvc在未完成CHAP握手前即放弃PDO生成。此逻辑违反SCSI标准，属厂商实现偏差。

六、诊断流程图：从表象到内核的纵深定位

graph TD
  A[现象：磁盘管理无LUN] --> B{diskpart → rescan → list disk?}
  B -- 空输出 --> C[检查StorSvc/VDS/iSCSI服务状态]
  B -- 显示磁盘 --> D[检查磁盘状态：online? clean?]
  C --> E[PowerShell: Get-Service StorSvc, vds, iscsiboot]
  E --> F{是否Running?}
  F -- 否 --> G[Set-Service -Name StorSvc -StartupType Automatic; Start-Service StorSvc]
  F -- 是 --> H[Event Viewer → Microsoft-Windows-Storage-Management/Operational]
  H --> I[筛选EventID 105/107/124：PDO发现失败、WMI提供程序超时]

七、根因验证矩阵：交叉印证关键指标

• ✅ Get-WmiObject -Namespace root\wmi -Class MSFT_Disk | ? {$_.BusType -eq 'iSCSI'} —— 若为空，确认VDS未获PDO
• ✅ Get-InitiatorSession | fl TargetNodeAddress, IsConnected, ConnectionStatus —— 验证会话级连通性
• ✅ wevtutil qe "Microsoft-Windows-Storage-Management/Operational" /q:"*[System[(EventID=105)]]" /f:text —— 查看“Failed to enumerate devices on bus”详情
• ✅ 在存储阵列端抓包过滤scsi.opcode == 0x12 && scsi.inquiry.vend == "MSFT" —— 确认Windows是否发出INQUIRY请求

八、修复优先级清单（按执行顺序）

1. 以管理员身份重启StorSvc、vds、isccsiboot服务
2. 执行diskpart → rescan后立即运行list disk
3. 禁用Windows防火墙临时测试（非生产环境）
4. 检查阵列LUN映射规则中IQN白名单与CHAP策略
5. 启用Microsoft-Windows-Storage-Management/Operational日志并复现
6. 使用procmon.exe监控storport.sys与vdsprov.dll的注册表/文件访问失败

九、架构视角：为何iscsicli成功 ≠ OS可见？

iSCSI登录仅建立TCP连接与Target Portal会话，属于网络层认证；而LUN对OS可见需完成存储栈四阶段交付：① iSCSI Initiator驱动上报SCSI总线至Storport → ② Storport创建PDO并触发PnP Manager枚举 → ③ VDS Provider监听PnP事件并调用WMI注册MSFT_Disk → ④ Disk Management MMC通过WMI消费数据。任一环断裂（尤以②→③间WMI通信失败最隐蔽），即导致“连接成功却不可见”。

十、高阶建议：面向多主机共享场景的健壮性加固

在Hyper-V集群或SQL Server AlwaysOn环境中，应部署iscsicli BindPersistentTarget绑定LUN至特定Session ID，并配合Set-StorageSubSystem -FriendlyName * -IsReadOnly $false确保StorSvc主动轮询。同时，在组策略中启用Computer Configuration → Administrative Templates → System → Device Installation → Allow administrators to override device installation restrictions，避免UAC策略二次拦截PDO安装。

```