简介面向VMware vSphere虚拟化平台运维与存储工程师提供一套来自某大厂实际生产环境的存储在线切换迁移完整方案解决存储设备升级、容量调整或容灾切换中必须保持虚拟机业务不中断的难题。方案内容共5章从迁移前必读的适用场景与注意事项入手详细列出基础信息统计、机房布线、ESXi主机光纤卡更换、系统状态检查与工具准备并规划目标端RAID组与LUN划分、SAN交换机配置及数据备份要求。迁移执行阶段演示了如何添加目标存储映射、利用vSphere热迁移在线搬移数据、移除源存储以及完成业务系统调测并对迁移后的I/O性能验证给出指引同时针对割接失败或异常情况给出了明确的数据备份与回退步骤便于及时止损。资源包为1个DOC格式文档大小1.92MB目录结构完整章节划分清晰可直接作为企业存储迁移项目参考。目前已有141人学习适合正在规划存储迁移或希望优化现有迁移流程的工程师、架构师。1. 为什么非换不可SC040 的存储迁移决策逻辑制造业大厂的生产虚拟化环境里DELL Compellent SC040 这种老存储往往是最先撑不住的那一环——剩余空间见底、控制器故障率往上走、微码版本老到厂商都快不维护了。但生产虚拟机不能停机于是 VMware Storage vMotion 就成了唯一现实的选择不改虚拟机配置、不重启业务把数据从 SC040 在线搬到 HPE 3PAR 20800v2。这套方案文档的含金量在于它不是讲 Storage vMotion 的通用教程而是一份可以直接照着操作的割接流程——从物理布线怎么切、LUN 状态什么时候能迁、到回退怎么走。适合虚拟化运维、存储工程师和负责业务连续性的人照着做能省掉大半现场摸索的时间。2. 迁移前一周准备环境盘查、机房布线与 16Gb HBA 卡更换2.1 基础信息三张表主机、交换机、源存储不能漏接手存储迁移的第一步不是去点 vCenter 里的迁移按钮而是先把现有的物理环境盘清楚。方案里强调了升级前 1 周就要做基础信息统计这个时间节点踩得很准——太早了信息容易变太晚了出了问题没时间改。统计范围是三类设备ESXi 主机、源端 SAN 交换机、源端存储每类一张表。我的习惯是主机表至少记这些字段品牌型号、序列号、主机名、业务地址、机柜位置、HBA 卡 WWN。特别注意 WWN 要记全后面在 3PAR 管理端映射 LUN 给主机时全靠它少一位都映射不上。交换机表要记微码版本和管理地址Brocade B300 这种老交换机在割接前后都要留底。源存储表重点记控制器微码版本、可用空间和机柜位置。# 用 esxcli 批量导出主机 HBA WWN比在 vCenter 图形界面一台台翻快得多 esxcli storage core adapter list | awk {print $1, $NF}这段命令的意思是把每台 ESXi 主机的存储适配器名称和对应的 WWN 一起列出来$NF取的是行尾的 WWN 字段。实际生产环境我建议直接在 vCenter 里逐个主机核对因为esxcli输出的 WWN 格式是 0x 开头的冒号分隔形式而存储端映射时需要的是naa.开头的格式两边要做一次转换核对。核对完别急着收工把每台主机到交换机端口的物理对应关系也写上后面改光纤线的时候能少走不少弯路。2.2 布线规划与 HBA 卡更换26 根光纤线先拿一台闲置主机试水方案里提到需要提前部署 13 台 ESXi 主机到两台目标 SAN 交换机 A/B 的光纤线每台主机两根总共 26 根。这里有个很容易被低估的细节光纤线不是插上就完事要提前布好并打好标签两端都要标清楚 A 端 B 端。现场割接的时候时间紧张手里拿着线头对不上端口表那感觉只能用血压拉满来形容。HBA 卡更换是这次迁移里最需要谨慎的硬件操作。源端 13 台 ESXi 主机用的是 8Gb 光纤卡目标 SAN 交换机是 16Gb不换卡链路带宽就卡在 8Gb。方案的做法是库里找 12 块闲置 16Gb 卡换给 6 台主机但换法很讲究——先拿一台闲置 ESXi 主机添加或更换光纤卡测试稳定后再动其余 5 台同型号主机不搞全面铺开。提示HBA 卡更换前确认主机在维护模式vCenter 里右键主机 → 进入维护模式等所有虚拟机迁走或关机后断电再操作。换完卡上电进 vCenter 确认 adapter 被正常识别、WWN 已更新再退出维护模式。2.3 运行状态检查和工具清单迁移前把风险项排干净在启动迁移之前方案里明确了要做一轮彻底的巡检包括业务运行状态、主机运行状态、源存储状态、光纤交换机状态四个维度。巡检不是走过场方案里专门提到要通重启主机、集群切换来验证业务系统真的健康——这一点很多团队不敢做但恰恰是最该做的。如果连重启和切换都经不起那在线迁移过程中的短暂 I/O 波动很可能直接打崩业务。网络层面要盯住 vmkernel 所在网卡的链路状态要求双千兆。这次巡检已经发现部分主机网卡降速为 10/100M这在迁移期间是个定时炸弹——vMotion 传输走存储网络还好但控制面信令如果走这张网卡降速会直接影响迁移任务稳定性。多路径状态也要检查本文场景用的是 VMware 自带 NMP 多路径软件要确认每条链路都是 active 状态没有 degraded 路径。工具清单看起来琐碎但缺一样都闹心。软件层面SSH 登录工具、FTP 工具、3PAR management console、DELL Compellent management console。硬件层面串口线RJ45 口、网线、防静电手套、标签纸、一台确认能接 RJ45 串口的笔记本。防静电手套这玩意儿很多人嫌麻烦不戴但在机房里拔插光纤模块时被静电打一下轻则端口 down重则设备重启这笔账自己掂量。3. 目标存储准备3PAR RAID/LUN 划分、Zone 规划与数据备份3.1 RAID 组与 LUN 划分从正在格式化到在线目标端 3PAR 20800v2 的准备工作分两个阶段先建 RAID 组和划分 LUN再把 LUN 映射给主机端口组。方案里 RAID 组和 LUN 规划是一张 30 行的卷清单实际生产里卷数量和容量完全取决于源存储上的数据量这张表的作用是让你逐行核对别到迁移时才发现目标存储空间算少了。划分 LUN 时有个状态机必须搞清楚新创建的 LUN 初始状态是正在格式化或者叫 zeroing这个阶段 LUN 可以配置但不能跑数据迁移。必须等全部 LUN 从正在格式化变成在线才能开始迁数据。如果不等格式化完成就强行迁移会出现数据写入异常最坏情况是迁移到一半目标 LUN 不可写虚拟机直接 I/O 错误挂起。提示3PAR 的 LUN 格式化本质是底层物理空间清零大容量 LUN 格式化耗时可能以小时计。规划时间表时要把这步算进去别把格式化时间和迁移时间安排在同一天。RAID 级别的选择要看业务对性能和冗余的平衡。生产虚拟机建议至少 RAID-5 或更高有条件的业务可以用 RAID-10。容量规划不是简单的源 LUN 总大小相加VMFS 文件系统自身有开销建议目标总容量按源数据量的 1.2 到 1.5 倍规划。方案里源存储向 ESXi 映射了 1 个 100G 的 LUN目标存储创建了 4 个 LUN2×100G、2×150G这就是考虑了扩容需求的典型做法——迁移时先用一个容量匹配的 LUN其余 LUN 留给后续业务扩容。3.2 目标端 SAN Zone 规划主机端口与存储 IOPORT 同 ZoneSAN 交换机规划的实质是打通主机到存储的链路。目标端要做的核心操作是把主机的端口和 3PAR 存储的 IOPORT 划入同一个 Zone 中并确保两个 Zone 分别落在两台交换机上做冗余。这里有两个常见做法需要说明第一Zone 命名建议包含主机名_存储名_交换机名三段式命名例如ESXI01_3PAR_SW_A。别用ZONE1、ZONE2这种流水号命名存储迁移项目的周期往往按周算回头排查链路问题时会发现自己根本不记得哪个 Zone 对应哪条链路。第二每台 ESXi 主机的两块 HBA 卡要分别连接两台 SAN 交换机也就是主机端做了链路冗余。Zone 划分时每台主机在两台交换机上各建一个 Zone每个 Zone 里包含该主机的一块 HBA 卡端口和 3PAR 的一个 IOPORT。这样即使一台交换机故障另一条链路仍能保持存储访问。配置完成后一定要做端到端确认。我的做法是在每台交换机上查看 Zone 内的端口是否都处于在线状态然后在 ESXi 主机上执行多路径扫描确认每个 LUN 都有两条 active 路径。如果看到只有单路径先查交换机的端口配置和 Zone 成员关系再查光纤线有没有插错端口——这两个问题占了 SAN 链路故障的八成以上。3.3 数据备份三层备份保住底线方案里数据备份分了三层第一层是业务配置信息包括集群、业务平台信息第二层是光纤交换机配置备份第三层是源存储上待迁移的数据用虚拟机快照做备份。这三层少哪层都不行。很多人觉得 Storage vMotion 是 vSphere 原生的在线迁移技术靠 VAAI 从存储层直接拷贝数据不会坏就不做备份。这是典型的侥幸心理——迁移过程中如果目标存储出现硬件故障、固件 bug、或者光纤链路闪断导致数据不一致没有备份就只能接受数据丢失的后果。虚拟机快照备份看起来很基础但在割接场景里它就是后悔药。提示快照要确认创建成功并且能正常删除别只做完快照就收工。迁移完成后要第一时间删除迁移前创建的旧快照否则快照文件会在源存储上持续占用空间而且会拖慢虚拟机性能。源存储上数据量大的话虚拟机快照备份的耗时也要提前预估。我在类似项目中的做法是迁移前一个工作日晚上创建快照第二天早上确认快照状态正常再进行迁移。这样既保证备份新鲜度又不至于让快照在源存储上停留太久。4. Storage vMotion 实操从物理连线到移除源存储4.1 物理连接变更先切一路迁移完成再切另一路方案里添加目标存储映射这一步估算时间按 120 分钟起这个估算是很现实的因为整个过程涉及物理改线、存储映射、主机 rescan、建数据存储四个环节链路越复杂耗时越长。以方案中的 ESX 双机集群为例源端架构是两台 ESXi 主机的 HBA 卡分别连到两台 Brocade B300 交换机再接到源存储 SC040。目标端接入 3PAR 20800v2 后组网变成混连状态。变更的先后顺序很讲究先拔掉 ESXi 到原 B300 交换机的一路光纤插入到连接 3PAR 的目标交换机的 1 路光纤此时主机还保留着到源存储的另一条链路存储访问不中断。等所有虚拟机迁移完成、业务验证通过后再把另一路光纤从 B300 交换机拔下来插到连接 3PAR 的目标交换机 2。如果你在手忙脚乱中把两路光纤同时切过去了而目标存储还没有完成 LUN 映射或者 Zone 配置主机可能完全丢失存储连接那就是不必要的生产事故。所以顺序必须是一次只动一路且先保证新链路路径可用再动另一路。4.2 LUN 映射与 rescan让 ESXi 集群识别目标存储物理改线完成后接下来的关键操作是把 3PAR 上格式化完成的 LUN 映射给 ESXi 主机。映射之前先要从 vCenter 里拿到 ESXi 主机的 HBA WWN找到对应主机查看Configuration → Hardware → Storage Adapters记下每块 HBA 卡的 WWN。拿到 WWN 后在 3PAR 的 ISM 管理软件里操作按照源存储的映射配置把 LUN 映射给 ESXi 主机。这里有个设计细节值得学习源存储只映射了 1 个 100G 的 LUN目标存储却创建了 4 个 LUN这是为了给后续扩容留空间同时也为了迁移时能按虚拟机分组落盘避免所有虚拟机挤在同一个 LUN 上。映射完成后ESXi 主机需要做一次 rescan 才能看到新 LUN。在 vCenter 里选择 ESXi 主机右键Configuration → Hardware → Storage Adapters在输出的 vmhba2 上选择 rescan。这里有个省事的机制同一集群内只要一台主机识别到目标存储的 LUN其他主机在默认配置下会自动识别。但我的建议是不要省这一步——手动逐台检查一遍确认每台主机的存储列表里都出现了目标 LUN。4.3 创建目标数据存储VMFS-5、命名与容量选择主机识别到 LUN 后还需要在 LUN 上创建 VMFS 文件系统也就是数据存储。vCenter 里进入 ESXi 主机的Configuration → Hardware → Storage点击Add Storage选择Disk/LUN此时会列出可用的 LUN目标存储映射过来的 LUN 就在其中。这里三个注意点第一一次只能选择一个磁盘。如果选中的磁盘容量不够创建完数据存储后要扩展而不能在创建时跨多个磁盘做条带。方案里明确提到一次只能选择一个磁盘这是很多人容易忽略的限制。第二文件系统版本选 VMFS-5。这个版本兼容性最好既能支持较新的 vSphere 版本又不会有 VMFS-6 在某些老环境里的兼容问题。方案里用了 VMFS-5如果你的 vCenter 和我一样跑在老版本上别试图赶时髦选 VMFS-6。第三命名要有继承性。方案里源数据存储叫mxy_stor_1目标存储命名为mxy_stor_dest一眼就能看出对应关系。实际项目中建议在命名里带日期或者批次信息比如3PAR_VMFS01_2025之类多个批次迁移时不会混淆。创建完成后在Storage视图里应该看到目标数据存储显示为可用状态、容量正确。此时别急着迁数据先在目标数据存储上右键 →属性确认文件系统版本是 VMFS-5、最大文件大小等信息正常。4.4 执行在线迁移右键虚拟机选更改存储数据存储准备好之后迁移的主体工作就是在 vCenter 里把虚拟机逐个从源存储移动到目标存储。选中要迁移的虚拟机右键 →迁移在迁移类型中选择仅更改存储然后在目的地里选择新创建的目标数据存储。不用改主机因为虚拟机还在原来那台 ESXi 上跑着Storage vMotion 的职责只是把磁盘文件从源数据存储复制到目标数据存储。执行后可以在 vCenter 的任务列表里看到迁移任务迁移过程中虚拟机保持开机状态业务不停。方案里迁移过程其实调用的是 FSDM/FS3DM 服务优先级是 Hardware FS3DM Software FS3DM FSDM。如果源端和目标端存储都支持 VAAI硬件卸载迁移走的是 Hardware FS3DM 数据路径——从源存储直接拷贝到目标存储传输走存储网络Kernel 只做信令验证。这意味着 Storage vMotion 的性能瓶颈在存储阵列本身而不是 ESXi 主机的 CPU 和网络这也是在线迁移能保持业务稳定的核心原因。4.5 迁移后清理移除源存储 LUN 与线缆全部虚拟机迁移完成后不能直接把源存储连接拔了要按顺序清理。第一步在 vCenter 里逐个确认所有需要迁移的虚拟机已经全部在目标数据存储上确认方式很简单——虚拟机的磁盘文件路径应该指向目标数据存储。第二步从 ESXi 主机上卸载unmount源数据存储。右键源数据存储 →卸载系统会检查是否还有虚拟机在使用它。如果还有虚拟机残留卸载会失败这时候需要回刚才的步骤确认遗漏的虚拟机。第三步从主机配置里移除detach源存储的 LUN。这个操作会断开主机与源存储的映射关系但不会删除源存储上的数据保留数据是为了回退留后路。最后一步才是物理上把光纤线从 B300 交换机完全断开插到目标交换机上完成整个组网切换。此时 Check 一下最终组网ESXi 主机 → 目标交换机 → 3PAR 存储一路走通。5. 避坑Storage vMotion 迁移中最容易翻车的五个点5.1 网卡协商到 10/100M迁移还没开始就输在起跑线现象巡检发现部分主机的 vmkernel 网卡链路协商速率降到了 10/100M按理说双千兆网卡不该出现这个速率。原因物理链路质量问题居多——网线老化、水晶头接触不良、对端交换机端口强制了特定速率。也可能是多路径配置异常导致 HBA 链路降速但网卡降速通常是物理层的锅。解决迁移前必须把降速的链路恢复。方法是先换网线再检查交换机端口配置确认两端协商模式一致如果问题还在检查物理适配器驱动和固件版本。方案里明确说迁移之前确保 vmkernel 所在网卡链路状态正常双千M这条不是建议是强制要求。5.2 LUN 还在正在格式化就被拉去迁移现象在 3PAR 上创建完 LUN 后直接开始 Storage vMotion 迁移迁移任务卡住或虚拟机 I/O 报错。原因LUN 创建后处于正在格式化zeroing状态这个状态下 LUN 可以配置映射但不能读写数据。VAAI 的硬件拷贝操作依赖目标存储完成物理空间清零底层没准备好拷贝自然进行不下去。解决等全部 LUN 状态变成在线再进行迁移。规划时间表时给格式化留出足够时间大容量 LUN 格式化几个小时的常见。迁移前检查一遍所有目标 LUN 的状态确认在线后再启动迁移一步都不能抢。5.3 共享磁盘做不了在线迁移只能离线现象虚拟机使用共享虚拟磁盘如 MSCS 集群节点共享盘右键迁移时发现 Storage vMotion 不可选或迁移失败。原因Storage vMotion 在线迁移不支持共享磁盘。VMFS 管理的非共享磁盘可以在线迁裸盘或共享 VMDK 只能走离线迁移——关机后迁或者加入额外的约束条件。解决迁移前先搞清楚虚拟机的磁盘类型如果使用了共享磁盘要么做离线迁移先关机再迁要么把共享盘排除在迁移范围之外。方案说明里专门标注了如果 VM 使用的盘为共享磁盘则只能做离线迁移这是 Storage vMotion 的功能边界别试图绕过。5.4 添加数据存储一次只能选一块盘容量不够要等建完再扩现象创建新数据存储时想把映射过来的多个 LUN 一次性全部选中做成一个大存储发现界面不支持。原因VMware 的 Add Storage 向导设计就是一次只能选一个 LUN 创建数据存储不支持多 LUN 聚合。这是产品功能限制不是操作失误。解决容量规划时把 LUN 大小切割合理创建数据存储后如果有扩容需求再执行扩容操作Extents 扩展把后续 LUN 加进去。方案里说得很清楚一次只能选择一个磁盘若容量不够创建成功后再扩容该数据存储。别在这个设计上纠结按它的规则走。5.5 VAAI 没激活Hardware FS3DM 不会生效现象迁移时发现传输走的是网络而非存储网络迁移速度明显低于预期ESXi 主机 CPU 负载异常上升。原因Storage vMotion 迁移时优先调用 Hardware FS3DM但前提是源端和目标端存储都支持 VAAI。如果有一端不支持或者 VAAI 功能没激活迁移会回退到 Software FS3DM 或者 FSDM数据走主机内存和网络转发性能大打折扣。解决迁移前用命令验证 VAAI 状态# 查看设备是否支持 VAAInaa 开头的 ID 替换成源存储的 LUN esxcli storage core device vaai status get -d naa.6000d31000430b0000000000000000331运行后看输出里的Hardware acceleration字段是否为Supported。两端都支持 VAAI 才能走 Hardware FS3DM 路径这是在线迁移性能的保底。如果发现不支持赶紧查存储的 VAAI 插件是否安装正确、存储端许可证是否激活不要等到迁移跑到一半才意识到走错了数据路径。6. 迁移后的验证与回退调测不达标怎么安全回到源端6.1 业务调测与倒换验证迁移完成后不急着宣布成功先做一轮业务调测。调测覆盖的范围要细致业务系统能否正常登录、数据库连接是否正常、集群服务是否健康以及跨主机的业务切换是否仍然顺畅。我在实际项目中习惯的做法是先虚机内的业务验证再跨主机的集群切换验证如 VMware HA最后存储链路验证确认所有 LUN 路径都是 active/optimized。调测过程如果发现业务异常先看 vCenter 事件和存储告警别急着回退。多数时候问题出在目标存储性能参数或 LUN 映射关系上这些小问题可以在目标端修正不用惊动源端。6.2 回退方案割接失败后怎么导回回退的前提是回退方案里三层备份都做了业务配置信息、交换机配置备份、源存储数据快照。割接失败导回的核心操作是把虚拟机在源存储上的数据恢复出来再把虚拟机重新关联回源数据存储迁移前创建的快照在此时发挥作用。如果回退发生在迁移早期源存储数据未删除、源存储连接未断开最直接的路径是把虚拟机关机用 Storage vMotion 反向迁移回源数据存储再按原配置恢复映射。如果回退发生在迁移后期源存储已离线则需要通过备份恢复到源存储。注意源存储离线后恢复时间会拉长这也是为什么方案里建议保留源存储 LUN 与数据直到业务验证完成。6.3 收尾习惯验收清单和复盘记录迁移完成且业务验证通过后我习惯强制自己做一遍完整的收尾复查确认同一集群内每台 ESXi 主机的存储适配器都能看到所有 LUN确认没有残留的虚拟机仍然引用源存储 LUN确认所有源存储的映射已解除最后把光纤线标记和交换机配置备份留档。做完这遍复查当天晚上的迁移才可以安心收工。从那以后的每次存储迁移我都强制先走一遍环境盘查、VAAI 验证、备份确认再动手改线顺序不乱、步骤不减宁可多花一小时做检查也不愿意凌晨三点站在机房里跟交换机端口较劲。这套方案文档里最值钱的部分不是 Storage vMotion 本身而是把怎么避风险和怎么回退都提前想清楚了。希望帮到你。本文还有配套的精品资源点击获取
