简介面向VMware vSphere平台运维与架构人员的一份存储在线切换迁移完整方案文档适用于存储设备升级替换、性能优化、容灾策略调整等典型场景。方案覆盖迁移前必读要点、环境与机房布线检查、ESXi主机光纤卡更换、RAID组与LUN划分、目标端SAN交换机规划、全量数据备份再到添加目标存储映射、虚拟化热迁移、源存储移除与业务调测并单独安排回退章节针对备份恢复与割接失败导回给出可执行步骤兼顾操作细节与风险控制。资源为1个doc文档压缩包共1个文件大小1.92MB打开即可按章节查阅命令式操作流程与割接规范。文档源自某制造业大厂实际项目沉淀目录结构完整既可作为同类虚拟化环境存储迁移的参考模板也能用于团队方案评审与操作培训。目前已有141人学习下载适合正在规划存储割接的虚拟化工程师直接借鉴。1. vSphere 存储在线切换到底在切什么从 LUN 概念到迁移链路你半夜收到存储告警连着 VMFS 数据存储的两个控制器一个风扇狂转厂商建议第二天上午更换控制器。如果你没有这套流程只能一台台关机迁移虚拟机等存储维护完再把业务拉起来——业务方大概率会在第二天早上找你喝咖啡。这篇文章要讲的是在大厂 vSphere 虚拟化平台上如何在虚拟机不关机、应用不中断的前提下把虚拟机连同数据从一块存储整体搬到另一块再安全退掉旧存储资源。这套方案统称存储在线切换迁移核心链路是存储 vMotion 加阵列侧配合覆盖 VMFS 数据存储和 RDM 裸设备映射两类场景。适合正在做存储扩容、阵列替换、机房搬迁或控制器维护的虚拟化运维工程师。2. 切换前先做对这四步回收空间、核对多路径与快照存储切换这件事失败往往不在切换那几分钟而在切换前没把环境状态摸清楚。我见过太多人上来就做 Storage vMotion结果跑到一半发现目标存储空间不够或者多路径没配对导致 IO 中断。前置检查是整套方案的地基下面四个维度缺一不可。2.1 先看架构哪些存储能跨阵列迁移哪些不能vSphere 平台的在线存储切换本质上分两个层面虚拟化层能看到的是数据存储Datastore存储层看到的是 LUN。你要迁的是虚拟机文件但切换的是后端存储资源。先说结论VMFS 数据存储上的虚拟机绝大多数都可以通过 Storage vMotion 在线迁移到任意主机可达的存储上跨阵列也没问题。限制主要在两类场景一是 RDM 物理模式Physical Compatibility Mode的裸设备映射虚拟机直接透传整个 LUN存储 vMotion 对它是透明的无法直接迁移二是虚拟机挂载了独立且无虚拟化层参与的设备比如 PCIe 直通、NVIDIA vGPU 配合的直通盘这类设备绑定了宿主机硬件资源在线迁移天然受限。所以第一步永远是盘点打开 vSphere Client逐个虚拟机查看磁盘类型标记出 RDM 和普通 VMDK。如果是 RDM 虚拟模式Virtual Compatibility Mode还有转换空间物理模式就得走存储侧镜像或应用层复制这个在第 4 章展开。另一个要确认的是链路类型。FC 存储和 iSCSI 存储的切换节奏完全不同FC 链路有 ALUA 和多路径调度控制器切换时主机侧几乎无感iSCSI 走以太网交换机的 STP 收敛、网卡卸载特性都会影响切换窗口。我一般会先在 vCenter 的存储设备视图里确认每个数据存储对应的 LUN 是 FC 还是 iSCSI 接入再决定后续操作步长。2.2 空间回收与容量核对别让迁移在最后一步失败目标存储的空间预留是前置检查里最容易翻车的环节。很多虚拟机最初创建时用的是厚置备延迟置零Thick Lazy Zeroed甚至厚置备快速清零Thick Eager Zeroed迁移时如果选了“转换磁盘格式为 Thin”空间占用看起来会变小反过来如果源是 Thin 而迁移目标强制 Thick容量需求会瞬间放大 1.3 到 2 倍。在批量迁移场景里这个放大效应会在十几台虚拟机之后直接把目标存储撑爆。实际操作里我一般用一个简单公式做容量预估目标存储可用空间 源虚拟机已用空间 快照 delta 文件大小乘以 1.3。多出来的 30% 是给 vMotion 临时缓存和存储侧快照用的。注意这里说的是“已用空间”不是“配置空间”。在数据存储摘要页看到的是配置空间在虚拟机编辑界面看到的是实际占用两者差距可以很大。做空间回收时还有两个细节值得花时间一是虚拟机内部删除的大文件不会自动回收到虚拟化层需要做一次碎片整理或 Storage vMotion 迁移回原存储来强制回收块二是过期快照。快照 delta 文件在迁移时会跟着一起走一个积累了三个月的旧快照可能占用几十 GB迁过去之后还会拖慢虚拟机的 IO。我之前处理过一台文件服务器迁移前快照占了 80GB清理合并之后虚拟机瞬间瘦身迁移时间从预计四小时缩到五十分钟。进一步还要逐台确认虚拟机磁盘的配置SCSI 控制器类型LSI Logic 还是 VMware PVSCSI、磁盘置备类型、是否开启 Fault Tolerance 容错。FT 虚拟机做存储 vMotion 有额外限制必须同时满足两个主机的资源匹配否则迁移按钮是灰色的。平台要求写不写都行但在大厂环境里 FT 虚拟机通常单独分组不参与通用的存储切换批次。2.3 多路径和队列深度检查两个必调参数存储在线切换最怕的就是路径抖动。控制器切换或 LUN 转移时主机侧路径会经历 Path Down、Active 路径切换、Rebuild 这几个状态如果多路径配置不对虚拟机的 IO 会直接中断数据库报错、应用卡死最终只能重启虚拟机。所以切换前必须检查每台主机的多路径状态。vSphere 默认的 NMP 路径策略有三种VMW_PSP_FIXED固定路径、VMW_PSP_MRU最近使用、VMW_PSP_RR轮转。对全闪存阵列或混合阵列RR 通常是最稳的选择因为它把 IO 分散到所有活跃路径控制器切换时的新路径也能被快速纳入。检查命令如下# 查看主机上所有存储设备和当前路径策略 esxcli storage nmp device list # 只看某个特定设备的多路径状态 esxcli storage nmp device list -d naa.6000a0b8000123456789abcdef0123 # 查看路径健康状态 esxcli storage core path list -d naa.6000a0b8000123456789abcdef0123跑完上面三条命令你要重点确认两件事第一每个 LUN 是否有多条 Active 路径如果只剩一条路径而且是 Dead存储切换还没开始你其实已经降级运行了第二路径策略是否符合阵列厂商建议3PAR 建议用 RR某些中端存储在故障切换时不建议用 MRU这个以存储管理软件里的官方兼容性为准。另外一个参数是磁盘的队列深度。Linux 虚拟机里数据库看到的 IO 延迟很高但存储侧压力并不大这种情况常见原因是 HBA 队列或 VMkernel 磁盘队列被占满。在 esxcli 里可以这样临时调整# 查看当前队列深度 esxcli storage core device list -d naa.6000a0b8000123456789abcdef0123 | grep -i queue # 调整队列深度到 128部分阵列上限 esxcli storage core device set -d naa.6000a0b8000123456789abcdef0123 -O 128注意-O参数在部分 vSphere 版本中并不可用需要到存储适配器层面调整。更稳妥的做法是确认阵列厂商的官方建议值然后通过 vCenter 高级参数统一设置而不是逐台主机临时改。2.4 快照与备份核对迁移失败的后悔药存储切换即使做得再稳也需要一道保险。我的习惯是在切换前对每一台参与迁移的虚拟机做一次无应用停顿的快照快照保留时间控制在 24 小时内确认迁移成功、存储 IO 稳定之后立即删除。这个快照不是给应用做备份而是给迁移操作本身兜底——万一切换过程中虚拟机状态异常你可以快速回滚到迁移前一刻。快照核对包括两个层面一是虚拟化层的虚拟机快照是否已经清理干净二是在存储侧确认旧 LUN 上是否还有存储阵列级快照任务在跑。曾经遇到过的情况是存储管理员在迁移前一天开了阵列快照任务迁移进行到一半阵列快照把 LUN 带宽占满vMotion 速度掉到几十 KB/s。所以迁移窗口开始前要明确和存储侧对齐暂停一切非必要的快照、复制、远程复制任务。备份状态也要看一眼。如果是数据库虚拟机确认最近的数据库备份任务已完成如果是关键业务的中间件节点确认配置备份已经打到离线位置。这一步不需要做恢复演练但至少要确认“真出问题时有东西能翻盘”。存储迁移切坏磁盘的概率不高但一旦发生往往就是灾难级现场备份是唯一的后悔药。做完上面四步检查你会得到一张清单哪些虚拟机可以走存储 vMotion哪些是 RDM 需要特殊处理目标存储的容量是否富余所有主机的多路径是否在健康状态。带着这张清单进入下一步操作才算真正准备好。3. 存储 vMotion 驱动的在线迁移操作序列与关键参数前置检查通过后进入真正的切换环节。这里主推的方案是存储 vMotion它能在虚拟机不停机的情况下把虚拟机的 VMDK 文件从源数据存储复制到目标数据存储复制完成后在极短的时间内切换 IO 路径。整个过程对运行在虚拟机里的业务是无感的理论丢包时间在秒级以内实际操作里多数虚拟机甚至感知不到。3.1 迁移的前置动作目标 LUN 映射与 VMFS 格式化目标存储不是插上就能用的。在存储侧创建好 LUN 之后还需要把 LUN 映射给要参与迁移的主机然后在 vSphere 里扫描存储适配器创建数据存储。这个顺序不能反先把存储映射做完再在虚拟化层做扫描。存储映射这一步通常由存储管理员操作在阵列管理软件里把新 LUN 映射到所有需要访问它的主机 WWPN 或 iSCSI IQN 上。映射完成后回到 vSphere每台主机的操作是# 重新扫描所有存储适配器发现新 LUN esxcli storage core adapter rescan --all # 确认新设备已出现 esxcli storage core device list | grep naa.6000 # 测试存储链路连通性用 vmkping 验证 VMkernel 到存储口的连通 vmkping -I vmk2 10.0.0.20关于vmkping多说一句它只能验证 IP 层的连通性不能替代真实的存储 IO 测试。如果 vmkping 通了但存储设备没有出现优先检查 LUN 映射的掩码Masking视图以及主机侧的存储适配器类型匹配关系。iSCSI 环境里还要额外确认 CHAP 认证没有拦截。扫描完成后把新 LUN 格式化为 VMFS 数据存储。我习惯把 VMFS 版本保持一致如果源存储是 VMFS6目标数据存储也建 VMFS6避免虚拟机文件跨版本时出现额外的兼容性适配。如果现有集群里有主机版本差异比如 6.7 和 7.0 混部VMFS 版本跟的是最低版本主机这个要留意。3.2 在线切换的三种方式图形界面操作序列与适用场景存储 vMotion 操作本身有三条路可走我按使用频率排序。第一种单台虚拟机在线迁移。适用于少数虚拟机、时间宽裕的场景。在 vSphere Client 里右键虚拟机 - 迁移 - 仅更改存储 - 选择目标数据存储 - 选择磁盘格式。这里的关键参数是磁盘格式保持原格式、Thin、Thick。默认保持原格式最安全但如果源存储分散碎片化严重建议顺手选 Thin既能瘦身又能顺便整理块。第二种批量迁移配合 vMotion 并行度控制。适用于几十台虚拟机的存储切换批次。关键在并发数控制不是所有虚拟机一起迁。vCenter 默认允许同时执行多个迁移任务但存储带宽是有限的。全闪阵列并发 4~6 台问题不大混闪或机械盘阵列建议并发 2~3 台否则迁移速度和生产业务 IO 互相抢带宽两边都慢。第三种跨 vCenter 的存储迁移。适用场景是数据中心拆分、机房级切换。这个场景不常用而且需要两个 vCenter 之间建立混合链接操作复杂度翻倍大厂操作手册里通常单独成章。对多数从业者来说把单 vCenter 内的存储在线切换跑通就够用了。三种方式的共同点是迁移期间不要对虚拟机做快照、不要调整虚拟机的 CPU 内存热设置、不要关闭虚拟机电源。如果 vMotion 任务长时间处于 0%先看存储 IO 是否有异常再看 vSphere 任务日志里是否有“Disk latency”相关的警告。3.3 批量迁移PowerCLI 脚本与限流参数生产环境里几十上百台虚拟机不可能一台台手点。用 PowerCLI 写一个带并发限流的迁移脚本是这套方案里最值得抄作业的部分。下面这个脚本我在多个环境里改过几版核心就两条按并发数分批、跳过不符合迁移条件的虚拟机。# 连接 vCenter建议用受控账号而非管理员 Connect-VIServer -Server vcenter01.corp.local -User svc_storage_migcorp.local -Password 变更前检查密码 # ---- 参数区按环境调整 ---- $sourceDS ds_old_array_01 # 源数据存储 $targetDS ds_new_array_02 # 目标数据存储 $concurrent 3 # 并发迁移数全闪可调到6 $diskFormat Thin # 目标磁盘格式Thin/Thick/Keep # ---- 获取源存储上已开机的虚拟机 ---- $vms Get-VM -Datastore $sourceDS | Where-Object { $_.PowerState -eq PoweredOn -and ($_ | Get-HardDisk | Where-Object {$_.StorageFormat -eq Thin}).Count -gt 0 } # ---- 分批迁移每批 $concurrent 台 ---- $total $vms.Count $batch 0 while ($batch -lt $total) { $currentBatch $vms | Select-Object -Skip $batch -First $concurrent foreach ($vm in $currentBatch) { Write-Host 迁移: $($vm.Name) # Move-VM 是核心命令-DiskStorageFormat 指定目标磁盘格式 Move-VM -VM $vm -Datastore (Get-Datastore -Name $targetDS) -DiskStorageFormat $diskFormat -Confirm:$false } # 等待当前批次完成避免下一批挤爆存储带宽 while ((Get-Task | Where-Object {$_.State -eq Running -and $_.ExtensionData.Info.DescriptionId -like *storage*}).Count -ge $concurrent) { Start-Sleep -Seconds 5 } $batch $concurrent } Disconnect-VIServer -Server vcenter01.corp.local -Confirm:$false脚本逻辑说明第一步连接 vCenter用最小权限账号是生产环境的底线存储迁移账号只需要虚拟机迁移权限和数据存储浏览权限不需要给管理员第二步筛选源数据存储上所有已开机虚拟机里面加了一个判断条件——只迁移含 Thin 磁盘的虚拟机这是因为厚置备磁盘在 Thin 目标上转换时 IO 放大更明显迁移时间不可控生产批次里我习惯先迁 Thin 再单独迁 Thick第三步循环迁移每批 $concurrent 台批之间通过 Get-Task 实时统计运行中的迁移任务数达到上限就 Sleep 5 秒再继续。实测中 $concurrent 设为 3对混合存储比较友好全闪阵列可以调到 6但前提是存储管理软件侧看到的阵列 CPU 不能有持续高负载。脚本跑完后立刻做一次全量核对查漏统计源数据存储上还有没有开机状态的虚拟机逐台确认它们的磁盘已经落在目标数据存储上。PowerCLI 核对命令# 找出源存储上仍然开机的虚拟机理论上应为空 Get-VM -Datastore $sourceDS | Where-Object {$_.PowerState -eq PoweredOn} # 统计目标存储上的虚拟机磁盘文件清单 Get-Datastore -Name $targetDS | Get-VM -Related | Select-Object Name, NumCpu, MemoryMB | Sort-Object Name3.4 迁移窗口确认从存储侧观察 IO 收敛虚拟机迁完不是终点。存储切换方案是否成功要看源 LUN 上的 IO 是否已经收敛归零。在 vSphere 中打开目标数据存储的“性能”面板观察磁盘读写延迟和 IOPS 是否平稳同时让存储管理员从阵列侧观察源 LUN 是否有持续的读写请求。如果虚拟机已经全部迁走源 LUN 上仍然有明显的 IO 活动大概率是某种后台任务还在占用比如虚拟机模板、ISO 库、或者某台被漏掉的虚拟机。我一般在确认所有虚拟机迁移完成后会保留源 LUN 观察 30 分钟以上再通知存储侧回收。这 30 分钟不是浪费而是给存储侧留出最后核对的时间窗口——确认没有日志报错、没有任务失败、没有遗留的磁盘锁。4. RDM 与裸设备映射常见做法和两组特例存储在线切换最难啃的骨头不是普通 VMDK而是 RDM。RDM 虚拟机直接把一个 LUN 映射给虚拟机使用虚拟化层只保存一个描述文件RDM pointer真正的数据和 IO 都直接穿透到存储 LUN 上。这类机器要在线切换存储不能只用存储 vMotion 扫一遍就完——需要分情况决策。4.1 RDM 迁移的两种选择Virtual Mode 映射转换RDM 分虚拟兼容模式Virtual Mode和物理兼容模式Physical Mode。Virtual Mode 的 RDM 磁盘在虚拟化层有一个虚拟 SCSI 控制器SCSI 指令会被虚拟化层翻译转发因此它具备被 vMotion 迁移的基础。Physical Mode 是完全透传SCSI 指令原封不动透传到底层虚拟化层无法介入。对 Virtual Mode 的 RDM迁移方案就是把 RDM 转换成 VMDK。操作路径虚拟机编辑设置 - 选中 RDM 磁盘 - 从虚拟机移除保留文件然后重新添加硬盘在“磁盘类型”里选“Thick Provision Eager Zeroed”或 Thin数据存储选目标存储把刚才移除的 RDM 数据复制过来。这个过程同样可以通过 Storage vMotion 完成vCenter 会识别 RDM 磁盘并自动拷贝。但这里有个坑RDM 磁盘转换成 VMDK 之后SCSI 设备 ID 会变。如果虚拟机里的数据库或应用绑定了固定磁盘标识比如 Oracle ASM 依赖的磁盘头需要在转换前把数据库层面的映射关系先解绑迁完后再重新绑定。ASM 场景尤其麻烦因为 ASM 实例要使用 ASMLib 或 udev 规则绑定磁盘VMDK 是不符合 ASM 磁盘发现机制的这类虚拟机通常排除在线迁移走存储侧阵列复制这个是很多大厂明确划分的边界。4.2 存储侧做镜像的场景整盘 LUN 迁移的取舍对 Physical Mode RDM 和无法接受 VMDK 转换的虚拟机唯一的在线手段是在存储阵列侧做 LUN 镜像或远程复制。3PAR 的 Volume Copy、v3700 的 Volume Mirror、EMC 的 SAN Copy各家存储都有类似能力。核心逻辑是在存储管理软件中把旧 LUN 的数据完整复制到新 LUN复制完成后切换虚拟机的映射路径让它指向新 LUN。这个方案的优点是不用碰虚拟机内部对应用零感知特别适合数据库集群、Oracle RAC、大数据节点这类对存储路径敏感的负载。缺点是需要存储侧有足够的空间和复制带宽而且复制过程本身会占用阵列资源。实际操作时我先看阵列剩余容量能否支撑整盘复制再看复制对源 LUN IO 的影响——如果复制时源 LUN 的延迟翻倍就要限制复制速率或者选业务低峰期执行。复制快完成时LUN 切换是风险最高的动作。虚拟机映射路径从旧 LUN 切到新 LUN 的瞬间需要主机重新识别设备——这个过程由存储侧做 LUN 的 mapping 切换由主机侧做 rescan。如果虚拟机的 SCSI 锁没有完全释放会出现两台主机同时争抢同一 LUN 的锁冲突极端情况下会导致 VMFS 锁损坏。稳妥的节奏是主机侧先把旧路径隔离再执行 rescan最后让存储侧卸载旧路径。每一步之间有 10~15 秒的间隔让虚拟化层的状态刷新稳定下来。4.3 控制器故障期间的在线切换一次现场复盘我在生产环境踩过最深的坑是存储控制器故障叠加在线迁移的场景。当时是一台中端存储的控制器电源模块异常存储厂商建议在线更换控制器。更换控制器意味着整个控制器要短暂下电所有映射到该控制器的 LUN 会经历控制器接管IO 路径在主机侧会全部切到另一块控制器。这种场景下如果前面的多路径配置没做好或者是阵列不支持自动控制器接管虚拟化层的主机就会报告 Device I/O 错误。那次复盘的教训是控制器切换前一定要先确认主机侧路径策略是 RR 或者 MRU并确保两个控制器的端口都映射到了主机。其次是在更换前 10 分钟停止一切批量迁移任务——迁移任务在读源写目标控制器切换瞬间的 IO 中断会让迁移任务直接失败而且重试时容易造成数据块不一致。另外控制器更换完成后不要马上把虚拟机迁回去。等存储侧确认缓存一致性、主机侧重新扫描路径后再操作。很多存储切换方案里最容易被忽略的就是回切步骤——原存储修复后要不要把虚拟机搬回去我的习惯是等两天确保原存储稳定才回切否则你会在三天内把整个切换流程再跑一遍。5. 存储切换避坑手册5 条一线踩坑记录存储在线切换的方案听起来不复杂真正动手时坑都在细节里。以下五条踩坑记录来自我从接触 vSphere 存储迁移到现在积累的真实教训每一条都按“现象 - 原因 - 解决”写清楚希望能让你少走一段弯路。5.1 旧存储始终显示“活动”无法正常卸载现象所有虚拟机都已经迁走源数据存储上已经没有开机状态的虚拟机但 vCenter 里这块旧 VMFS 数据存储的状态仍然是“活动”卸载时提示有主机正在使用。原因极少数宿主机上还残留着旧 LUN 的路径可能是某台主机没有成功重扫描或者是 vSphere 的存储资源仍然引用了这个数据存储。还有一种是旧存储上存在虚拟机的挂起状态Suspended挂起虚拟机虽然在迁移时被视为已关机但它内存文件还锁在源存储上。解决先把所有挂起虚拟机恢复或彻底打开确认没有任何虚拟机文件包括挂起的 .vmsn 文件在源存储上。然后在每台主机上执行esxcli storage core device list -d naa.xxx | grep -i state检查旧设备是否处于“on”状态。最后在 vSphere Client 里右键数据存储 - 卸载。如果主机报告设备忙先重启该主机的 storage management 服务/etc/init.d/vmware-storaged restart需要谨慎生产环境至少先咨询厂商另一个更稳妥的办法是在主机维护模式下单独操作。5.2 存储侧设为只读数据库虚拟机直接报 IO 错误现象为了保险存储管理员把旧 LUN 切换成只读然后通知虚拟化侧可以做最后的数据校验。结果虚拟机上运行的数据库开始大量报错日志显示“I/O error”部分应用进程直接挂掉。原因虚拟机对磁盘的写操作没有被阻塞而是直接报错。vSphere 对只读 LUN 的写入不会在虚拟化层拦截而是把 IO 请求下发到存储存储返回“介质被写保护”后虚拟化层再返回给虚拟机。操作系统里的数据库进程往往无法正确识别这个错误直接当成磁盘 IO 故障处理。解决不要对在线虚拟机的存储 LUN 做只读切换。如果必须做只读保护时机是虚拟机全部关机或迁移完成之后。真正的在线迁移顺序是先保证旧 LUN 不被任何虚拟机写入用主机侧路径缩短把旧路径标记为 Dead来阻断新写入而不是在存储侧粗暴设为只读。5.3 批量迁移到一半目标存储空间告急现象PowerCLI 脚本跑到第 20 台虚拟机目标数据存储的剩余空间从 40% 掉到 5%迁移任务大面积失败已经迁了一半的虚拟机无法回滚处于“无磁盘文件”的中间状态。原因容量预估只算了虚拟机的已用空间没有考虑到厚置备磁盘的转换放大。源存储上有多台虚拟机的磁盘是 Thick 格式虽然已用空间不大但迁移时默认“保持原格式”会让目标存储保留同等大小的 Thick 块空间占用瞬间放大好几倍。解决批量迁移脚本里强制指定-DiskStorageFormat Thin或者在容量预估阶段用目标存储可用空间除以源虚拟机配置空间总和确保比例大于 1 才启动。已迁移一半的虚拟机没有回滚的必要——迁移失败时虚拟机会保留在源存储不会丢失数据只需调整空间后重新执行迁移即可。5.4 迁移后虚拟机开不了机报“找不到磁盘”错误现象一台虚拟机迁移到新数据存储后开机时提示“Disk is not present”、“无效设备操作”之类的错误虚拟机无法正常启动。原因这台虚拟机挂载了 RDM 磁盘或 CD-ROM 设备迁移过程中 RDM 的映射文件没有跟过来或者虽然跟过来了但目标数据存储上没有对应的设备路径。还有可能是迁移时 SCSI 控制器编号发生了变化源是 SCSI 1:0被自动调整成了 SCSI 0:0导致 vmx 文件引用的磁盘节点不存在。解决先看虚拟机 vmx 文件的磁盘引用路径是否都在新数据存储下存在。RDM 类型的虚拟机不要用“仅更改存储”的方式迁移要先转换 RDM 为 VMDK或者走存储侧复制。SCSI 编号变化的打开虚拟机编辑设置手动把每个磁盘的控制器位置改回原值重启虚拟机验证。5.5 光纤交换机割接导致迁移任务全部中断现象计划做存储切换的那天正好赶上光纤交换机固件升级割接。迁移任务跑到一半vCenter 里大量任务报错几个数据库虚拟机的 IO 延迟瞬间飙升到几百毫秒。原因光纤交换机在重启或切换固件时用了 30 秒以上的时间完成链路收敛。存储 vMotion 的数据流在中途被切断任务重试机制要等链路恢复重建但虚拟机业务 IO 也被卡在同一链路上两边抢带宽最终互相拖垮。解决割接和存储迁移不要放在同一窗口。如果时间冲突无法避免把迁移任务暂停等割接完成、存储路径全部恢复后再继续。另外光纤交换机割接前先确认虚拟化层到存储的每个 LUN 都有至少两条物理路径并且路径经过不同交换机。两条路径都在同一台交换机上割接就是单点故障。6. 回退与验证让下线存储随时能“反悔”的兜底技巧存储切换方案做到最后回退能力比切换速度更能体现水平。大厂方案里最容易被忽略的是“旧存储不要急着回收”。我的习惯是虚拟机全部迁走后旧 LUN 继续保留 72 小时期间数据存储不卸载、不销毁、不对存储侧做破坏性操作。保留三天的理由很简单很多问题不是切换后立刻暴露的可能是某个数据库在第二天早上才发现一张临时表找不到路径或者是某个应用因为 SCSI 锁延迟在半夜报了错。旧存储还在回退就只是重新挂载的问题旧存储清了回退就得从备份里恢复时间成本完全不是一个量级。切换完成后的验证建议分三层做。第一层是虚拟化层每台虚拟机确认位于目标数据存储磁盘文件状态正常打开虚拟机电源并观察几分钟CPU 和内存开销正常。第二层是应用层对数据库虚拟机确认数据库实例正常、监听端口正常、无异常错误日志对应用服务虚拟机确认健康检查接口的响应时间和切换前无明显差异。第三层是性能层在 esxtop 中按d键查看设备延迟DAVG/GAVG和切换前的基线对比如果延迟有翻倍级增长说明目标存储的存储池或网络链路存在瓶颈需要进一步排查。# 用 esxtop 检查存储设备延迟按 d 进磁盘视图 # DAVG 是设备延迟GAVG 是包含 VMkernel 排队的总延迟 # 正常情况下 DAVG 应保持在个位数毫秒量级数据库盘可放宽到 10ms 以内 esxtop最后还有一个实用技巧在新存储上做一次“试点迁移”。不要一口气把全部虚拟机迁过去先选两台低负载但真实的业务虚拟机做全流程验证从存储映射、迁移执行到旧存储保留把全链路跑通。试点成功后再接批大队这个习惯帮我至少避免过两次大规模翻车。我在做这类方案时血泪经验是在线迁移最大的风险往往不是技术本身而是流程上太顺、太大意——觉得几天都没出问题就提前把旧存储回收了结果回退通道被自己亲手斩断。现在我的习惯是存储切换完成后把旧 LUN 做一次快照再进入保留期快照保留到确认稳定后自然过期。这样做既不占用太多空间又给回退留了一根保险绳。希望这些踩坑和收尾的习惯能帮到你让你做存储在线切换时少一点提心吊胆。本文还有配套的精品资源点击获取
vSphere存储在线切换全指南：从LUN迁移到存储vMotion实战
简介面向VMware vSphere平台运维与架构人员的一份存储在线切换迁移完整方案文档适用于存储设备升级替换、性能优化、容灾策略调整等典型场景。方案覆盖迁移前必读要点、环境与机房布线检查、ESXi主机光纤卡更换、RAID组与LUN划分、目标端SAN交换机规划、全量数据备份再到添加目标存储映射、虚拟化热迁移、源存储移除与业务调测并单独安排回退章节针对备份恢复与割接失败导回给出可执行步骤兼顾操作细节与风险控制。资源为1个doc文档压缩包共1个文件大小1.92MB打开即可按章节查阅命令式操作流程与割接规范。文档源自某制造业大厂实际项目沉淀目录结构完整既可作为同类虚拟化环境存储迁移的参考模板也能用于团队方案评审与操作培训。目前已有141人学习下载适合正在规划存储割接的虚拟化工程师直接借鉴。1. vSphere 存储在线切换到底在切什么从 LUN 概念到迁移链路你半夜收到存储告警连着 VMFS 数据存储的两个控制器一个风扇狂转厂商建议第二天上午更换控制器。如果你没有这套流程只能一台台关机迁移虚拟机等存储维护完再把业务拉起来——业务方大概率会在第二天早上找你喝咖啡。这篇文章要讲的是在大厂 vSphere 虚拟化平台上如何在虚拟机不关机、应用不中断的前提下把虚拟机连同数据从一块存储整体搬到另一块再安全退掉旧存储资源。这套方案统称存储在线切换迁移核心链路是存储 vMotion 加阵列侧配合覆盖 VMFS 数据存储和 RDM 裸设备映射两类场景。适合正在做存储扩容、阵列替换、机房搬迁或控制器维护的虚拟化运维工程师。2. 切换前先做对这四步回收空间、核对多路径与快照存储切换这件事失败往往不在切换那几分钟而在切换前没把环境状态摸清楚。我见过太多人上来就做 Storage vMotion结果跑到一半发现目标存储空间不够或者多路径没配对导致 IO 中断。前置检查是整套方案的地基下面四个维度缺一不可。2.1 先看架构哪些存储能跨阵列迁移哪些不能vSphere 平台的在线存储切换本质上分两个层面虚拟化层能看到的是数据存储Datastore存储层看到的是 LUN。你要迁的是虚拟机文件但切换的是后端存储资源。先说结论VMFS 数据存储上的虚拟机绝大多数都可以通过 Storage vMotion 在线迁移到任意主机可达的存储上跨阵列也没问题。限制主要在两类场景一是 RDM 物理模式Physical Compatibility Mode的裸设备映射虚拟机直接透传整个 LUN存储 vMotion 对它是透明的无法直接迁移二是虚拟机挂载了独立且无虚拟化层参与的设备比如 PCIe 直通、NVIDIA vGPU 配合的直通盘这类设备绑定了宿主机硬件资源在线迁移天然受限。所以第一步永远是盘点打开 vSphere Client逐个虚拟机查看磁盘类型标记出 RDM 和普通 VMDK。如果是 RDM 虚拟模式Virtual Compatibility Mode还有转换空间物理模式就得走存储侧镜像或应用层复制这个在第 4 章展开。另一个要确认的是链路类型。FC 存储和 iSCSI 存储的切换节奏完全不同FC 链路有 ALUA 和多路径调度控制器切换时主机侧几乎无感iSCSI 走以太网交换机的 STP 收敛、网卡卸载特性都会影响切换窗口。我一般会先在 vCenter 的存储设备视图里确认每个数据存储对应的 LUN 是 FC 还是 iSCSI 接入再决定后续操作步长。2.2 空间回收与容量核对别让迁移在最后一步失败目标存储的空间预留是前置检查里最容易翻车的环节。很多虚拟机最初创建时用的是厚置备延迟置零Thick Lazy Zeroed甚至厚置备快速清零Thick Eager Zeroed迁移时如果选了“转换磁盘格式为 Thin”空间占用看起来会变小反过来如果源是 Thin 而迁移目标强制 Thick容量需求会瞬间放大 1.3 到 2 倍。在批量迁移场景里这个放大效应会在十几台虚拟机之后直接把目标存储撑爆。实际操作里我一般用一个简单公式做容量预估目标存储可用空间 源虚拟机已用空间 快照 delta 文件大小乘以 1.3。多出来的 30% 是给 vMotion 临时缓存和存储侧快照用的。注意这里说的是“已用空间”不是“配置空间”。在数据存储摘要页看到的是配置空间在虚拟机编辑界面看到的是实际占用两者差距可以很大。做空间回收时还有两个细节值得花时间一是虚拟机内部删除的大文件不会自动回收到虚拟化层需要做一次碎片整理或 Storage vMotion 迁移回原存储来强制回收块二是过期快照。快照 delta 文件在迁移时会跟着一起走一个积累了三个月的旧快照可能占用几十 GB迁过去之后还会拖慢虚拟机的 IO。我之前处理过一台文件服务器迁移前快照占了 80GB清理合并之后虚拟机瞬间瘦身迁移时间从预计四小时缩到五十分钟。进一步还要逐台确认虚拟机磁盘的配置SCSI 控制器类型LSI Logic 还是 VMware PVSCSI、磁盘置备类型、是否开启 Fault Tolerance 容错。FT 虚拟机做存储 vMotion 有额外限制必须同时满足两个主机的资源匹配否则迁移按钮是灰色的。平台要求写不写都行但在大厂环境里 FT 虚拟机通常单独分组不参与通用的存储切换批次。2.3 多路径和队列深度检查两个必调参数存储在线切换最怕的就是路径抖动。控制器切换或 LUN 转移时主机侧路径会经历 Path Down、Active 路径切换、Rebuild 这几个状态如果多路径配置不对虚拟机的 IO 会直接中断数据库报错、应用卡死最终只能重启虚拟机。所以切换前必须检查每台主机的多路径状态。vSphere 默认的 NMP 路径策略有三种VMW_PSP_FIXED固定路径、VMW_PSP_MRU最近使用、VMW_PSP_RR轮转。对全闪存阵列或混合阵列RR 通常是最稳的选择因为它把 IO 分散到所有活跃路径控制器切换时的新路径也能被快速纳入。检查命令如下# 查看主机上所有存储设备和当前路径策略 esxcli storage nmp device list # 只看某个特定设备的多路径状态 esxcli storage nmp device list -d naa.6000a0b8000123456789abcdef0123 # 查看路径健康状态 esxcli storage core path list -d naa.6000a0b8000123456789abcdef0123跑完上面三条命令你要重点确认两件事第一每个 LUN 是否有多条 Active 路径如果只剩一条路径而且是 Dead存储切换还没开始你其实已经降级运行了第二路径策略是否符合阵列厂商建议3PAR 建议用 RR某些中端存储在故障切换时不建议用 MRU这个以存储管理软件里的官方兼容性为准。另外一个参数是磁盘的队列深度。Linux 虚拟机里数据库看到的 IO 延迟很高但存储侧压力并不大这种情况常见原因是 HBA 队列或 VMkernel 磁盘队列被占满。在 esxcli 里可以这样临时调整# 查看当前队列深度 esxcli storage core device list -d naa.6000a0b8000123456789abcdef0123 | grep -i queue # 调整队列深度到 128部分阵列上限 esxcli storage core device set -d naa.6000a0b8000123456789abcdef0123 -O 128注意-O参数在部分 vSphere 版本中并不可用需要到存储适配器层面调整。更稳妥的做法是确认阵列厂商的官方建议值然后通过 vCenter 高级参数统一设置而不是逐台主机临时改。2.4 快照与备份核对迁移失败的后悔药存储切换即使做得再稳也需要一道保险。我的习惯是在切换前对每一台参与迁移的虚拟机做一次无应用停顿的快照快照保留时间控制在 24 小时内确认迁移成功、存储 IO 稳定之后立即删除。这个快照不是给应用做备份而是给迁移操作本身兜底——万一切换过程中虚拟机状态异常你可以快速回滚到迁移前一刻。快照核对包括两个层面一是虚拟化层的虚拟机快照是否已经清理干净二是在存储侧确认旧 LUN 上是否还有存储阵列级快照任务在跑。曾经遇到过的情况是存储管理员在迁移前一天开了阵列快照任务迁移进行到一半阵列快照把 LUN 带宽占满vMotion 速度掉到几十 KB/s。所以迁移窗口开始前要明确和存储侧对齐暂停一切非必要的快照、复制、远程复制任务。备份状态也要看一眼。如果是数据库虚拟机确认最近的数据库备份任务已完成如果是关键业务的中间件节点确认配置备份已经打到离线位置。这一步不需要做恢复演练但至少要确认“真出问题时有东西能翻盘”。存储迁移切坏磁盘的概率不高但一旦发生往往就是灾难级现场备份是唯一的后悔药。做完上面四步检查你会得到一张清单哪些虚拟机可以走存储 vMotion哪些是 RDM 需要特殊处理目标存储的容量是否富余所有主机的多路径是否在健康状态。带着这张清单进入下一步操作才算真正准备好。3. 存储 vMotion 驱动的在线迁移操作序列与关键参数前置检查通过后进入真正的切换环节。这里主推的方案是存储 vMotion它能在虚拟机不停机的情况下把虚拟机的 VMDK 文件从源数据存储复制到目标数据存储复制完成后在极短的时间内切换 IO 路径。整个过程对运行在虚拟机里的业务是无感的理论丢包时间在秒级以内实际操作里多数虚拟机甚至感知不到。3.1 迁移的前置动作目标 LUN 映射与 VMFS 格式化目标存储不是插上就能用的。在存储侧创建好 LUN 之后还需要把 LUN 映射给要参与迁移的主机然后在 vSphere 里扫描存储适配器创建数据存储。这个顺序不能反先把存储映射做完再在虚拟化层做扫描。存储映射这一步通常由存储管理员操作在阵列管理软件里把新 LUN 映射到所有需要访问它的主机 WWPN 或 iSCSI IQN 上。映射完成后回到 vSphere每台主机的操作是# 重新扫描所有存储适配器发现新 LUN esxcli storage core adapter rescan --all # 确认新设备已出现 esxcli storage core device list | grep naa.6000 # 测试存储链路连通性用 vmkping 验证 VMkernel 到存储口的连通 vmkping -I vmk2 10.0.0.20关于vmkping多说一句它只能验证 IP 层的连通性不能替代真实的存储 IO 测试。如果 vmkping 通了但存储设备没有出现优先检查 LUN 映射的掩码Masking视图以及主机侧的存储适配器类型匹配关系。iSCSI 环境里还要额外确认 CHAP 认证没有拦截。扫描完成后把新 LUN 格式化为 VMFS 数据存储。我习惯把 VMFS 版本保持一致如果源存储是 VMFS6目标数据存储也建 VMFS6避免虚拟机文件跨版本时出现额外的兼容性适配。如果现有集群里有主机版本差异比如 6.7 和 7.0 混部VMFS 版本跟的是最低版本主机这个要留意。3.2 在线切换的三种方式图形界面操作序列与适用场景存储 vMotion 操作本身有三条路可走我按使用频率排序。第一种单台虚拟机在线迁移。适用于少数虚拟机、时间宽裕的场景。在 vSphere Client 里右键虚拟机 - 迁移 - 仅更改存储 - 选择目标数据存储 - 选择磁盘格式。这里的关键参数是磁盘格式保持原格式、Thin、Thick。默认保持原格式最安全但如果源存储分散碎片化严重建议顺手选 Thin既能瘦身又能顺便整理块。第二种批量迁移配合 vMotion 并行度控制。适用于几十台虚拟机的存储切换批次。关键在并发数控制不是所有虚拟机一起迁。vCenter 默认允许同时执行多个迁移任务但存储带宽是有限的。全闪阵列并发 4~6 台问题不大混闪或机械盘阵列建议并发 2~3 台否则迁移速度和生产业务 IO 互相抢带宽两边都慢。第三种跨 vCenter 的存储迁移。适用场景是数据中心拆分、机房级切换。这个场景不常用而且需要两个 vCenter 之间建立混合链接操作复杂度翻倍大厂操作手册里通常单独成章。对多数从业者来说把单 vCenter 内的存储在线切换跑通就够用了。三种方式的共同点是迁移期间不要对虚拟机做快照、不要调整虚拟机的 CPU 内存热设置、不要关闭虚拟机电源。如果 vMotion 任务长时间处于 0%先看存储 IO 是否有异常再看 vSphere 任务日志里是否有“Disk latency”相关的警告。3.3 批量迁移PowerCLI 脚本与限流参数生产环境里几十上百台虚拟机不可能一台台手点。用 PowerCLI 写一个带并发限流的迁移脚本是这套方案里最值得抄作业的部分。下面这个脚本我在多个环境里改过几版核心就两条按并发数分批、跳过不符合迁移条件的虚拟机。# 连接 vCenter建议用受控账号而非管理员 Connect-VIServer -Server vcenter01.corp.local -User svc_storage_migcorp.local -Password 变更前检查密码 # ---- 参数区按环境调整 ---- $sourceDS ds_old_array_01 # 源数据存储 $targetDS ds_new_array_02 # 目标数据存储 $concurrent 3 # 并发迁移数全闪可调到6 $diskFormat Thin # 目标磁盘格式Thin/Thick/Keep # ---- 获取源存储上已开机的虚拟机 ---- $vms Get-VM -Datastore $sourceDS | Where-Object { $_.PowerState -eq PoweredOn -and ($_ | Get-HardDisk | Where-Object {$_.StorageFormat -eq Thin}).Count -gt 0 } # ---- 分批迁移每批 $concurrent 台 ---- $total $vms.Count $batch 0 while ($batch -lt $total) { $currentBatch $vms | Select-Object -Skip $batch -First $concurrent foreach ($vm in $currentBatch) { Write-Host 迁移: $($vm.Name) # Move-VM 是核心命令-DiskStorageFormat 指定目标磁盘格式 Move-VM -VM $vm -Datastore (Get-Datastore -Name $targetDS) -DiskStorageFormat $diskFormat -Confirm:$false } # 等待当前批次完成避免下一批挤爆存储带宽 while ((Get-Task | Where-Object {$_.State -eq Running -and $_.ExtensionData.Info.DescriptionId -like *storage*}).Count -ge $concurrent) { Start-Sleep -Seconds 5 } $batch $concurrent } Disconnect-VIServer -Server vcenter01.corp.local -Confirm:$false脚本逻辑说明第一步连接 vCenter用最小权限账号是生产环境的底线存储迁移账号只需要虚拟机迁移权限和数据存储浏览权限不需要给管理员第二步筛选源数据存储上所有已开机虚拟机里面加了一个判断条件——只迁移含 Thin 磁盘的虚拟机这是因为厚置备磁盘在 Thin 目标上转换时 IO 放大更明显迁移时间不可控生产批次里我习惯先迁 Thin 再单独迁 Thick第三步循环迁移每批 $concurrent 台批之间通过 Get-Task 实时统计运行中的迁移任务数达到上限就 Sleep 5 秒再继续。实测中 $concurrent 设为 3对混合存储比较友好全闪阵列可以调到 6但前提是存储管理软件侧看到的阵列 CPU 不能有持续高负载。脚本跑完后立刻做一次全量核对查漏统计源数据存储上还有没有开机状态的虚拟机逐台确认它们的磁盘已经落在目标数据存储上。PowerCLI 核对命令# 找出源存储上仍然开机的虚拟机理论上应为空 Get-VM -Datastore $sourceDS | Where-Object {$_.PowerState -eq PoweredOn} # 统计目标存储上的虚拟机磁盘文件清单 Get-Datastore -Name $targetDS | Get-VM -Related | Select-Object Name, NumCpu, MemoryMB | Sort-Object Name3.4 迁移窗口确认从存储侧观察 IO 收敛虚拟机迁完不是终点。存储切换方案是否成功要看源 LUN 上的 IO 是否已经收敛归零。在 vSphere 中打开目标数据存储的“性能”面板观察磁盘读写延迟和 IOPS 是否平稳同时让存储管理员从阵列侧观察源 LUN 是否有持续的读写请求。如果虚拟机已经全部迁走源 LUN 上仍然有明显的 IO 活动大概率是某种后台任务还在占用比如虚拟机模板、ISO 库、或者某台被漏掉的虚拟机。我一般在确认所有虚拟机迁移完成后会保留源 LUN 观察 30 分钟以上再通知存储侧回收。这 30 分钟不是浪费而是给存储侧留出最后核对的时间窗口——确认没有日志报错、没有任务失败、没有遗留的磁盘锁。4. RDM 与裸设备映射常见做法和两组特例存储在线切换最难啃的骨头不是普通 VMDK而是 RDM。RDM 虚拟机直接把一个 LUN 映射给虚拟机使用虚拟化层只保存一个描述文件RDM pointer真正的数据和 IO 都直接穿透到存储 LUN 上。这类机器要在线切换存储不能只用存储 vMotion 扫一遍就完——需要分情况决策。4.1 RDM 迁移的两种选择Virtual Mode 映射转换RDM 分虚拟兼容模式Virtual Mode和物理兼容模式Physical Mode。Virtual Mode 的 RDM 磁盘在虚拟化层有一个虚拟 SCSI 控制器SCSI 指令会被虚拟化层翻译转发因此它具备被 vMotion 迁移的基础。Physical Mode 是完全透传SCSI 指令原封不动透传到底层虚拟化层无法介入。对 Virtual Mode 的 RDM迁移方案就是把 RDM 转换成 VMDK。操作路径虚拟机编辑设置 - 选中 RDM 磁盘 - 从虚拟机移除保留文件然后重新添加硬盘在“磁盘类型”里选“Thick Provision Eager Zeroed”或 Thin数据存储选目标存储把刚才移除的 RDM 数据复制过来。这个过程同样可以通过 Storage vMotion 完成vCenter 会识别 RDM 磁盘并自动拷贝。但这里有个坑RDM 磁盘转换成 VMDK 之后SCSI 设备 ID 会变。如果虚拟机里的数据库或应用绑定了固定磁盘标识比如 Oracle ASM 依赖的磁盘头需要在转换前把数据库层面的映射关系先解绑迁完后再重新绑定。ASM 场景尤其麻烦因为 ASM 实例要使用 ASMLib 或 udev 规则绑定磁盘VMDK 是不符合 ASM 磁盘发现机制的这类虚拟机通常排除在线迁移走存储侧阵列复制这个是很多大厂明确划分的边界。4.2 存储侧做镜像的场景整盘 LUN 迁移的取舍对 Physical Mode RDM 和无法接受 VMDK 转换的虚拟机唯一的在线手段是在存储阵列侧做 LUN 镜像或远程复制。3PAR 的 Volume Copy、v3700 的 Volume Mirror、EMC 的 SAN Copy各家存储都有类似能力。核心逻辑是在存储管理软件中把旧 LUN 的数据完整复制到新 LUN复制完成后切换虚拟机的映射路径让它指向新 LUN。这个方案的优点是不用碰虚拟机内部对应用零感知特别适合数据库集群、Oracle RAC、大数据节点这类对存储路径敏感的负载。缺点是需要存储侧有足够的空间和复制带宽而且复制过程本身会占用阵列资源。实际操作时我先看阵列剩余容量能否支撑整盘复制再看复制对源 LUN IO 的影响——如果复制时源 LUN 的延迟翻倍就要限制复制速率或者选业务低峰期执行。复制快完成时LUN 切换是风险最高的动作。虚拟机映射路径从旧 LUN 切到新 LUN 的瞬间需要主机重新识别设备——这个过程由存储侧做 LUN 的 mapping 切换由主机侧做 rescan。如果虚拟机的 SCSI 锁没有完全释放会出现两台主机同时争抢同一 LUN 的锁冲突极端情况下会导致 VMFS 锁损坏。稳妥的节奏是主机侧先把旧路径隔离再执行 rescan最后让存储侧卸载旧路径。每一步之间有 10~15 秒的间隔让虚拟化层的状态刷新稳定下来。4.3 控制器故障期间的在线切换一次现场复盘我在生产环境踩过最深的坑是存储控制器故障叠加在线迁移的场景。当时是一台中端存储的控制器电源模块异常存储厂商建议在线更换控制器。更换控制器意味着整个控制器要短暂下电所有映射到该控制器的 LUN 会经历控制器接管IO 路径在主机侧会全部切到另一块控制器。这种场景下如果前面的多路径配置没做好或者是阵列不支持自动控制器接管虚拟化层的主机就会报告 Device I/O 错误。那次复盘的教训是控制器切换前一定要先确认主机侧路径策略是 RR 或者 MRU并确保两个控制器的端口都映射到了主机。其次是在更换前 10 分钟停止一切批量迁移任务——迁移任务在读源写目标控制器切换瞬间的 IO 中断会让迁移任务直接失败而且重试时容易造成数据块不一致。另外控制器更换完成后不要马上把虚拟机迁回去。等存储侧确认缓存一致性、主机侧重新扫描路径后再操作。很多存储切换方案里最容易被忽略的就是回切步骤——原存储修复后要不要把虚拟机搬回去我的习惯是等两天确保原存储稳定才回切否则你会在三天内把整个切换流程再跑一遍。5. 存储切换避坑手册5 条一线踩坑记录存储在线切换的方案听起来不复杂真正动手时坑都在细节里。以下五条踩坑记录来自我从接触 vSphere 存储迁移到现在积累的真实教训每一条都按“现象 - 原因 - 解决”写清楚希望能让你少走一段弯路。5.1 旧存储始终显示“活动”无法正常卸载现象所有虚拟机都已经迁走源数据存储上已经没有开机状态的虚拟机但 vCenter 里这块旧 VMFS 数据存储的状态仍然是“活动”卸载时提示有主机正在使用。原因极少数宿主机上还残留着旧 LUN 的路径可能是某台主机没有成功重扫描或者是 vSphere 的存储资源仍然引用了这个数据存储。还有一种是旧存储上存在虚拟机的挂起状态Suspended挂起虚拟机虽然在迁移时被视为已关机但它内存文件还锁在源存储上。解决先把所有挂起虚拟机恢复或彻底打开确认没有任何虚拟机文件包括挂起的 .vmsn 文件在源存储上。然后在每台主机上执行esxcli storage core device list -d naa.xxx | grep -i state检查旧设备是否处于“on”状态。最后在 vSphere Client 里右键数据存储 - 卸载。如果主机报告设备忙先重启该主机的 storage management 服务/etc/init.d/vmware-storaged restart需要谨慎生产环境至少先咨询厂商另一个更稳妥的办法是在主机维护模式下单独操作。5.2 存储侧设为只读数据库虚拟机直接报 IO 错误现象为了保险存储管理员把旧 LUN 切换成只读然后通知虚拟化侧可以做最后的数据校验。结果虚拟机上运行的数据库开始大量报错日志显示“I/O error”部分应用进程直接挂掉。原因虚拟机对磁盘的写操作没有被阻塞而是直接报错。vSphere 对只读 LUN 的写入不会在虚拟化层拦截而是把 IO 请求下发到存储存储返回“介质被写保护”后虚拟化层再返回给虚拟机。操作系统里的数据库进程往往无法正确识别这个错误直接当成磁盘 IO 故障处理。解决不要对在线虚拟机的存储 LUN 做只读切换。如果必须做只读保护时机是虚拟机全部关机或迁移完成之后。真正的在线迁移顺序是先保证旧 LUN 不被任何虚拟机写入用主机侧路径缩短把旧路径标记为 Dead来阻断新写入而不是在存储侧粗暴设为只读。5.3 批量迁移到一半目标存储空间告急现象PowerCLI 脚本跑到第 20 台虚拟机目标数据存储的剩余空间从 40% 掉到 5%迁移任务大面积失败已经迁了一半的虚拟机无法回滚处于“无磁盘文件”的中间状态。原因容量预估只算了虚拟机的已用空间没有考虑到厚置备磁盘的转换放大。源存储上有多台虚拟机的磁盘是 Thick 格式虽然已用空间不大但迁移时默认“保持原格式”会让目标存储保留同等大小的 Thick 块空间占用瞬间放大好几倍。解决批量迁移脚本里强制指定-DiskStorageFormat Thin或者在容量预估阶段用目标存储可用空间除以源虚拟机配置空间总和确保比例大于 1 才启动。已迁移一半的虚拟机没有回滚的必要——迁移失败时虚拟机会保留在源存储不会丢失数据只需调整空间后重新执行迁移即可。5.4 迁移后虚拟机开不了机报“找不到磁盘”错误现象一台虚拟机迁移到新数据存储后开机时提示“Disk is not present”、“无效设备操作”之类的错误虚拟机无法正常启动。原因这台虚拟机挂载了 RDM 磁盘或 CD-ROM 设备迁移过程中 RDM 的映射文件没有跟过来或者虽然跟过来了但目标数据存储上没有对应的设备路径。还有可能是迁移时 SCSI 控制器编号发生了变化源是 SCSI 1:0被自动调整成了 SCSI 0:0导致 vmx 文件引用的磁盘节点不存在。解决先看虚拟机 vmx 文件的磁盘引用路径是否都在新数据存储下存在。RDM 类型的虚拟机不要用“仅更改存储”的方式迁移要先转换 RDM 为 VMDK或者走存储侧复制。SCSI 编号变化的打开虚拟机编辑设置手动把每个磁盘的控制器位置改回原值重启虚拟机验证。5.5 光纤交换机割接导致迁移任务全部中断现象计划做存储切换的那天正好赶上光纤交换机固件升级割接。迁移任务跑到一半vCenter 里大量任务报错几个数据库虚拟机的 IO 延迟瞬间飙升到几百毫秒。原因光纤交换机在重启或切换固件时用了 30 秒以上的时间完成链路收敛。存储 vMotion 的数据流在中途被切断任务重试机制要等链路恢复重建但虚拟机业务 IO 也被卡在同一链路上两边抢带宽最终互相拖垮。解决割接和存储迁移不要放在同一窗口。如果时间冲突无法避免把迁移任务暂停等割接完成、存储路径全部恢复后再继续。另外光纤交换机割接前先确认虚拟化层到存储的每个 LUN 都有至少两条物理路径并且路径经过不同交换机。两条路径都在同一台交换机上割接就是单点故障。6. 回退与验证让下线存储随时能“反悔”的兜底技巧存储切换方案做到最后回退能力比切换速度更能体现水平。大厂方案里最容易被忽略的是“旧存储不要急着回收”。我的习惯是虚拟机全部迁走后旧 LUN 继续保留 72 小时期间数据存储不卸载、不销毁、不对存储侧做破坏性操作。保留三天的理由很简单很多问题不是切换后立刻暴露的可能是某个数据库在第二天早上才发现一张临时表找不到路径或者是某个应用因为 SCSI 锁延迟在半夜报了错。旧存储还在回退就只是重新挂载的问题旧存储清了回退就得从备份里恢复时间成本完全不是一个量级。切换完成后的验证建议分三层做。第一层是虚拟化层每台虚拟机确认位于目标数据存储磁盘文件状态正常打开虚拟机电源并观察几分钟CPU 和内存开销正常。第二层是应用层对数据库虚拟机确认数据库实例正常、监听端口正常、无异常错误日志对应用服务虚拟机确认健康检查接口的响应时间和切换前无明显差异。第三层是性能层在 esxtop 中按d键查看设备延迟DAVG/GAVG和切换前的基线对比如果延迟有翻倍级增长说明目标存储的存储池或网络链路存在瓶颈需要进一步排查。# 用 esxtop 检查存储设备延迟按 d 进磁盘视图 # DAVG 是设备延迟GAVG 是包含 VMkernel 排队的总延迟 # 正常情况下 DAVG 应保持在个位数毫秒量级数据库盘可放宽到 10ms 以内 esxtop最后还有一个实用技巧在新存储上做一次“试点迁移”。不要一口气把全部虚拟机迁过去先选两台低负载但真实的业务虚拟机做全流程验证从存储映射、迁移执行到旧存储保留把全链路跑通。试点成功后再接批大队这个习惯帮我至少避免过两次大规模翻车。我在做这类方案时血泪经验是在线迁移最大的风险往往不是技术本身而是流程上太顺、太大意——觉得几天都没出问题就提前把旧存储回收了结果回退通道被自己亲手斩断。现在我的习惯是存储切换完成后把旧 LUN 做一次快照再进入保留期快照保留到确认稳定后自然过期。这样做既不占用太多空间又给回退留了一根保险绳。希望这些踩坑和收尾的习惯能帮到你让你做存储在线切换时少一点提心吊胆。本文还有配套的精品资源点击获取
