服务器虚拟化后看不到存储，绝大多数情况不是硬件故障，而是存储协议配置未对齐、LUN映射未生效或驱动未被宿主识别，虚拟化与存储的关联本质上是把物理磁盘抽象成统一资源池，再通过数据存储（Datastore）分配给虚拟机。
虚拟化存储无法识别原因排查
先确认存储类型是否匹配
虚拟化平台对存储的类型有严格取舍,本地盘、外置磁盘阵列、SAN和NAS在宿主眼里是不同物种，多数用户遇到“看不到存储”，第一步就犯了大忌：拿直连存储（DAS）的思路去对待共享存储，本地盘装完系统就能识别，但共享存储必须经过网络协议、存储阵列映射、宿主扫描三层关卡。
- 本地SATA/SAS盘：默认可见，无需额外配置。
- FC SAN存储：需要光纤HBA卡、Zone配置、LUN Masking。
- iSCSI存储：需要网络连通、软件适配器启用、目标端认证。
- NFS存储：需要网络共享路径和挂载权限。
如果你配置的是FC或iSCSI存储,却直接用浏览本地磁盘的方式去找，自然一无所获。
检查LUN映射与Zone配置
存储阵列上的LUN就像一个上了锁的房间,必须给宿主发门禁卡，LUN Masking（LUN遮蔽）没做对，存储端看得到宿主，宿主却拿不到磁盘，FC环境还要检查交换机上的Zone配置，Zone不包含宿主WWN，光纤链路就是一根废线。
业内专家指出,近半数存储不可见问题出在Zoning和LUN Mapping的配置遗漏上，而不是硬件损坏。
驱动与HBA卡状态
ESXi宿主的存储驱动栈比物理机敏感得多,HBA卡固件版本过旧、驱动不兼容、队列深度设置不当，都会导致存储设备在扫描时静默丢失，从 vSphere Client 进入“主机 → 存储 → 存储适配器”，如果适配器状态为“离线”或“未知”，先重启该适配器，再重新扫描存储。
多路径与重复路径冲突
多路径软件（如PowerPath、Native Multipathing）配置混乱时，宿主机可能把同一物理LUN识别成两个不同设备，导致VMFS文件系统无法挂载，表现也是“看不到存储”，用 esxcli storage nmp device list 查看路径信息，确认Active路径数量是否为正常值。
虚拟化与存储关联机制解析
数据存储、VMDK、VMFS三者的关系
虚拟化存储的基石是文件系统与封装格式的配合,ESXi把物理LUN格式化为VMFS（虚拟机文件系统），虚拟机磁盘（VMDK）作为文件存放在其中，宿主之所以看不到“裸磁盘”，是因为它看到的不是块设备，而是文件。
VMDK文件在虚拟机内部才表现为一块磁盘,这就是为什么你在宿主上用 fdisk -l 看不到任何VMDK分区，但虚拟机系统里却能看到完整磁盘的原因。
FC、iSCSI、NFS对比
三种主流存储连接协议各有性格,选错协议是“看不见存储”的第一诱因。
| 协议 | 传输载体 | 性能表现 | 配置复杂度 | 常见使用场景 |
|---|---|---|---|---|
| FC | 光纤专线 | 高且稳定 | 高 | 核心数据库、大规模虚拟化集群 |
| iSCSI | 千兆/万兆以太网 | 受网络影响大 | 中 | 中小规模虚拟化、灾备链路 |
| NFS | 以太网 | 中高 | 低 | 轻量级应用、快速部署场景 |
行业共识认为,iSCSI是性价比最高的入门方案，但如果网络抖动过大，宿主机直接丢失存储路径，虚拟机体验会极差。
存储识别路径的三个环节
宿主机访问存储要经过“物理链路 → 存储协议层 → 文件系统层”三步，物理链路指网卡、光纤线、交换机状态；协议层负责目标的发现与登录；文件系统层决定能否创建数据存储，任何一个环节断裂，vSphere中的“存储”视图就空空如也。
VMware虚拟化存储挂载步骤
iSCSI软件适配器配置流程
这是裸金属物理机迁移到虚拟化后最常见的“找存储”场景，以VMware ESXi 7.0及以上版本为例：
- 在vSphere Client中选择宿主机，进入“配置 → 存储适配器”。
- 点击“添加软件适配器”，选择“iSCSI适配器”。
- 在适配器属性中启用“已启用”状态，并填写iSCSI发起端IQN。
- 切到“动态发现”选项卡，输入存储阵列的IP地址和端口（默认3260）。
- 点击“重新扫描存储”。
- 等待数秒后进入“存储”视图，确认新数据存储是否出现。
NFS数据存储创建流程
NFS挂载是Linux运维工程师最容易上手的虚拟化存储方案：
- 存储端共享出NFS目录,
/data/vmstore。 - 确认网络路由可达,挂载选项启用NFS v3或v4.1。
- 在vSphere Client中选择宿主机，点击“存储 → 新建数据存储”。
- 选择“NFS”类型，填写共享文件夹路径。
- 完成后在存储列表中即可看到该数据存储,虚拟机的VMDK文件会被放置在这个路径下。
命令行验证与排错
SSH登录宿主机,常用命令：
esxcli storage core device list：列出所有识别到的存储设备。esxcli storage filesystem list：查看已挂载的文件系统。vmkping -I vmk1 10.0.0.5：测试iSCSI存储网络连通性。esxcfg-mpath -l：显示多路径状态。
如果执行 esxcli storage core device list 有输出但 filesystem list 为空，说明设备已可见但LUN尚未格式化或VMFS卷未挂载。
虚拟化存储性能调优与容量规划
多路径策略选择
路径策略直接影响IO分布,VMware默认的“最近使用”（MRU）策略适合单一激活路径；SAP、Oracle等IO密集型应用建议切换到“固定”或“循环”策略，修改方式：
- 进入“主机 → 存储 → 存储设备”。
- 选择LUN设备,点“属性”。
- 在“管理路径”中修改路径策略为
Round Robin（循环）。 - 设置IO计数限制,例如1000，让路径在负载达到阈值时切换。
队列深度与IO延迟
存储队列深度好比每个设备能同时处理的IO请求数量,队列太浅，高并发时宿主直接报设备繁忙，表现为存储超时、虚拟机卡死。
- HBA队列深度：HBA卡BIOS或驱动参数中调整，常用值为64到256。
- iSCSI软件适配器队列深度：在
esxcli storage core device set命令中调整。 - 固态存储队列深度通常高于机械盘,具体值参考存储厂商最佳实践。
容量规划按场景区分
虚拟化存储规划不能一刀切,管理类虚拟机（AD域控、DHCP、监控平台）用NFS卷即可；交易类核心系统建议直接映射RDM设备，让数据库容器直接操作底层LUN，绕过VMFS文件系统开销，容器化平台（Kubernetes）则优先考虑CSI接口的容器存储插件，动态创建PV卷。
从预算角度看,服务器虚拟化存储采购成本对比场景中，入门级iSCSI方案每TB成本明显低于FC方案，但延迟普遍高20%以上，具体选择取决于业务容忍度。
存储可见性检查清单
遇到“存储丢失”问题，按顺序排查：
- 存储阵列管理界面确认LUN状态为“在线”。
- 确认宿主启动器WWN/IQN已被添加到存储主机组。
- 检查交换机端口、网卡、光纤线链路状态是否为Up。
- 在存储端查看是否记录到宿主端的登录日志。
- 重置存储适配器并重新扫描,再刷新存储视图。
- 检查VMware日志文件：
/var/log/vmkernel.log中搜索LUN或device
虚拟化与存储的关联并不复杂,核心是理解“宿主看到的是数据存储，而不是物理磁盘”，不再把物理盘当唯一依赖，运维思路就顺了。
虚拟化存储常见问题解答
为什么虚拟机磁盘部署在数据存储上，但我SSH进宿主机用fdisk看不到VMDK？
VMDK是文件,不是块设备，fdisk操作的是物理块设备，所以看不到VMDK，验证VMDK是否存在，应查看数据存储的文件目录：进入vSphere Client，选择数据存储 → 浏览文件，SSH下用 find /vmfs/volumes/datastore1 -name ".vmdk" 进行确认。
虚拟化存储和传统物理服务器直连存储有什么区别？
物理服务器直连存储只能单机独享,虚拟化存储必须被所有宿主共享访问，直连存储坏了就宕机，虚拟化共享存储天然支持VMotion在线迁移和HA故障切换，这也是虚拟化架构必须采购SAN或NAS而非继续买本地盘的核心原因。
把虚拟机从老旧存储迁移到新存储阵列，业务会不会中断？
使用Storage vMotion在线迁移不会中断，迁移过程中虚拟机会生成一个临时快照，内存状态和IO持续同步到新存储，所有磁盘块复制完成后自动切换锚点，若使用共享存储热迁移，需要确保新旧阵列均被同一集群识别，并避免混合LUN使用不同块大小影响VMFS兼容性。
存储问题排查到驱动和协议层基本就可以画句号,先从物理链路扫描开始，再用 esxcli 抓设备状态，最后检查数据存储挂载点，大部分“看不见存储”的问题都能在十分钟内定位到具体环节。