简介面向VMware vSphere运维与存储工程师的完整迁移方案文档以某制造业大厂虚拟化平台在线切换迁移为实例系统梳理存储迁移的规划、执行与回退全流程。资源为1个doc文件压缩包大小1.92MB内容结构清晰既可作为项目评审材料也可直接打印为现场操作手册。文档从迁移前必读入手明确适用场景和注意事项详细展开环境准备环节涵盖基础信息统计、机房布线、ESXi主机光纤卡更换、系统运行状态检查、工具准备以及目标存储RAID组与LUN规划、SAN交换机规划、数据备份等前置工作正文给出添加目标存储映射、在线迁移虚拟机、迁移后移除源存储、业务系统调测的具体操作步骤。尤其值得关注的是文档单独设置回退方案章节针对数据备份与恢复、割接失败导回等场景提供回退步骤强化迁移风险控制。已有139人学习下载适合存储替换、性能优化与容灾调整项目的技术团队参考。1. 从一次存储整列退役说起vSphere 在线存储迁移到底解决什么问题存储阵列每三到五年就要换一轮控制器到维保末期、固件不再更新或者业务要求从机械盘池整体切到全闪池。直接把虚拟机停机再拷走在今天的大厂环境里几乎不可行——数据库和消息队列断十分钟上下游对账与应用监控就会一起告警。vSphere 平台的存储在线切换迁移要解决的就是让虚拟机在持续运行状态下把 VMDK、快照链和配置文件从一个数据存储整体搬到另一个数据零丢失业务侧只感知到最后一两秒的存储 IO 抖动。落地这项能力的核心机制叫 Storage vMotion。这套方案面向虚拟化运维、存储工程师和负责维护窗口的架构师覆盖原理、前置条件、单台迁移、批量自动化与收尾验证产物是一套能直接进变更单的完整动作流程。2. Storage vMotion 的工作原理与前置条件为什么能在线又为什么不能跨集群乱迁2.1 svMotion 的读写路径全量拷贝、差量跟踪与原地址即时切换Storage vMotion 的在线不是靠快照恢复而是靠三个阶段接力。迁移启动后ESXi 会在目标数据存储上创建同规格的新 VMDK并把源盘的存量数据按块拷贝过去与此同时虚拟机照常运行新增的写请求会同时反映到源盘和目标盘的变更记录里保证两边的数据视图不分裂。拷贝接近完成时宿主机进入切换阶段短暂暂停虚拟机把增量部分补齐到目标端更新虚拟机配置文件里的磁盘路径指向然后恢复运行。整个过程虚拟机不关机guest 里不需要改任何配置SCSI 磁盘、网卡和 UUID 由 vCenter 平滑接管。理解这条路径对排错很有价值。迁移总时长由存量拷贝决定瓶颈通常在目标存储的写入吞吐或迁移流量所走网络带宽切换时长则取决于增量大小也就是拷贝期间业务产生了多少写量。大厂环境里一个常见误判是只评估磁盘容量、不评估写密度——一个单日写入 2TB、磁盘容量只有 800GB 的虚拟机增量阶段可能反复追不上迁移任务长时间停在切换中而误以为卡死。提示svMotion 的迁移数据走 vMotion 的 VMkernel 接口没有单独配置 vMotion 网络的集群流量会落到管理网络迁移速度和管理面稳定性互相影响。有条件就单独加一个 vMotion vmknic并把 MTU 统一到 9000。2.2 迁移前必须核对的环境清单版本、存储类型、网络与硬件兼容性版本上先把底线说清Storage vMotion 从 ESX 4.1 时代就有但 vSphere 6.5 之后才支持无共享存储的跨主机迁移shared-nothing svMotion6.7 到 7.0 才逐步完善跨 vCenter 迁移和加密迁移。大厂环境里最常见的组合是 vSphere 6.7/7.0/8.0 集群界面路径和命令基本一致但跨大版本集群之间做 svMotion要提前核对 EVC 模式与虚拟机兼容性。前置条件按下面这张表逐项核检查项要求核错会怎样vCenter 与 ESXi 版本源、目标集群同版本且由同一 vCenter 纳管任务直接失败或回滚目标数据存储容量大于源端总使用量加快照链总和拷贝中途报 InsufficientSpace 并回滚磁盘格式目标存储支持 Thin / Thick 中至少一种格式转换后空间翻倍不报错但容量失真存储多路径目标 LUN 的 PSP 与路径状态已核对拷贝慢或切换阶段 IO 超时网络vMotion VMkernel 接口 MTU 两端一致大数据包被丢任务反复重试虚拟机硬件版本虚拟硬件 v7 及以上界面里更改数据存储选项直接置灰多路径是这里最容易被看起来正常骗过的一项。目标存储里的 LUN 如果采用 FIXED固定路径策略主路径失效后 ESXi 切换到备用路径需要数秒这段时间的存储延迟会从毫秒级跳到秒级如果恰好撞上切换阶段虚拟机里的数据库会话可能直接中断。迁移前把目标存储的 PSP 策略、每条路径的 Active 状态都拉一遍是合情合理的变更前动作。2.3 哪些情况不能在线迁移RDM、共享 VMDK 与快照链边界第一类是物理 RDM裸设备映射。svMotion 只搬文件型 VMDK物理兼容模式的 RDM 不会出现在迁移向导中必须先转换为虚拟兼容模式或者用整盘克隆方式重新挂载。第二类是共享 VMDK典型场景是 Windows 故障转移集群里的共享仲裁盘多台虚拟机同时引用同一个 VMDK 文件svMotion 不感知共享语义迁移后锁机制可能被破坏。大厂处理这类集群盘常见做法是只迁各节点的系统盘和数据盘共享盘随集群级别整体切换。第三类是链接克隆。链接克隆的 delta 盘依赖父盘文件单独迁移克隆体而不迁父盘会导致磁盘链断裂。处理办法是迁移前做一次快照合并或者把整个克隆组连同父盘规划进同一次迁移批次。还有一类容易被忽略但在存储整列退役时必然踩到的边界如果这次迁移的最终目的是源存储彻底下线要先在集群设置里把 vSphere HA 的存储心跳数据存储从源存储上摘掉再执行迁移否则最后一台虚拟机迁走后心跳组件因找不到数据存储而反复告警整个存储退役流程会被拉长。3. 单台虚拟机在线切换的最小可复现流程从 Web Client 到 esxcli 核对3.1 Web Client 里完成一次更改数据存储的完整操作路径vCenter 的 vSphere Client 里右键虚拟机 → 迁移 → 迁移类型选仅更改存储Change storage only。第二步选择目标数据存储目标既可以是本地 VMFS也可以是 NFS 挂载卷或 vSAN 分布式存储上的数据存储随后决定磁盘格式与源相同Same format as source保留原有 Thin/Thick 属性最稳妥推荐默认。精简置备Thin Provisioned按实际使用量分配空间适合全闪且容量紧张的环境。厚置备延迟置零Lazy Zeroed预分配空间但不立即写零适合批处理类低延迟敏感业务。厚置备急切置零Eager Zeroed预分配并全盘写零vSphere 官方推荐给数据库类 IO 密集业务。第三步核对源和目标数据存储容量与网络兼容性确认后 vCenter 会创建一条重新定位虚拟机的任务。任务执行期间虚拟机保持运行业务侧只看到磁盘延迟轻微波动不需要安排业务停机。如果虚拟机挂载了多块磁盘迁移向导允许分盘指定目标——把系统盘落到全闪池、数据盘落到大容量 SATA 池这是分层存储方案里很常见的用法。这里有一个我通常会坚持的习惯磁盘格式选择与源相同不要在手术窗口里同时改磁盘属性和存储路径。等业务低峰期再用磁盘属性里的紧凑或转换为精简做一次带内格式优化比在迁移时顺手改格式更可控。3.2 用 esxcli 在 ESXi 层面确认存储设备与多路径状态迁移前在虚拟机所在宿主机上做一次存储健康核验。SSH 登录 ESXi需要先在 DCUI 或 vCenter 里开启 ESXi Shell 与 SSH 服务执行# 列出所有存储设备确认目标 LUN 的 naa 标识、容量与状态 esxcli storage core device list | grep -w naa. # 查看指定 LUN 的多路径状态Expected Paths 与 Working Paths 必须一致 esxcli storage core path list --device naa.6000c29e0e2f4f000000000000000000 # 查看 VMFS 卷与 LUN 的映射关系确认目标存储已正常挂载 esxcli storage vmfs extent list如果 Working Paths 小于 Expected Paths说明阵列端还有链路没映射到位或光纤交换机的 zone 没放完这种状态迁过去大概率慢且不稳。多路径策略用esxcli storage nmp device list查看必要时把 PSP 改为轮询模式# 查看当前 LUN 的 PSP 策略与主路径 esxcli storage nmp device list --device naa.6000c29e0e2f4f000000000000000000 # 将 FIXED 改为 ROUND_ROBIN适合绝大多数全闪阵列 esxcli storage nmp set --device naa.6000c29e0e2f4f000000000000000000 --psp VMW_PSP_RR说明这些命令不是迁移本身必需的步骤但大厂做存储切换时存储团队经常只报一句路径已配好实际是否有冗余路径、首选路径是否指向正确的控制器ESXi 侧必须自己再确认一遍。把每条路径都跑一次 path list 核对 Active能省掉迁移后一半以上的 IO 性能排查。3.3 迁移结果验证用 vmkfstools 与目录结构核对新磁盘类型任务显示完成后登录目标存储所在宿主机进入该虚拟机的数据存储目录# 查看目标目录中的文件构成VMDK、VMX、VSWP 是否齐全 ls -lh /vmfs/volumes/new-flash-ds01/webserver-01/ # 查看 VMDK 描述文件确认 diskType、createType 与容量字段 vmkfstools -T /vmfs/volumes/new-flash-ds01/webserver-01/webserver-01.vmdk # 对比源端目录确认没有同名 vmdk 残留 ls -lh /vmfs/volumes/old-ds01/webserver-01/正常输出里 diskType 为 VMFScreateType 与源端一致容量字段等于该虚拟机磁盘的标称值。如果目标目录里出现-flat.vmdk与描述性 vmdk 大小不匹配说明拷贝不完整或中途有人手工干预要立刻查看 vCenter 的任务历史。源端目录里残留的.vswp和空目录是 vSphere 清理机制延迟几分钟内会回收超过 24 小时还在且同名 vmdk 仍被某个虚拟机配置引用那多半是共享盘不要手工删除回到 vCenter 里确认磁盘映射关系后再处理。4. 批量切换的节奏控制用 PowerCLI 在一轮维护窗口内迁完一个存储池4.1 先盘存量统计源存储上的虚拟机、磁盘与快照分布一个承载几百台虚拟机的大存储池靠 Web Client 一台台点迁移既慢又容易被审计挑毛病。PowerCLI 是 vSphere 官方支持的批量管理方式安装 VMware.PowerCLI 模块后执行# 连接 vCenter域账号或本地管理员均可 Connect-VIServer -Server vc01.example.com -Protocol https # 归集源存储上的所有虚拟机并计算磁盘总量 $src Get-Datastore -Name old-ds01 $vms Get-VM -Datastore $src $vms | Select-Object Name, {NTotalDiskGB;E{[math]::Round((($_.HardDisks | Measure-Object CapacityGB -Sum).Sum), 1)}}, {NHasSnapshot;E{($_.Snapshot).Count -gt 0}} | Sort-Object TotalDiskGB -Descending | Export-Csv C:\work\ds01_inventory.csv -NoTypeInformation脚本逻辑说明Get-VM -Datastore $src按数据存储归集虚拟机Measure-Object CapacityGB统计的是虚拟磁盘的标称容量不是实际占用对 Thin 盘会偏大但这正是排迁移顺序时需要的——把标称容量大的放前面避免维护窗口被超大虚拟机占满。HasSnapshot用于筛出带快照的虚拟机带快照的迁移时间明显拉长建议单独分一批。导出的 CSV 直接贴到变更单里作为迁移顺序和审计依据。如果源存储上还躺着模板和 ISO 文件用Get-Template单独归集模板迁移不占用 svMotion 任务直接复制文件更快。4.2 批量迁移脚本按依赖分批、单个确认、错误即中断# 从清单 CSV 批量执行 svMotion保持磁盘格式不变 $srcDS old-ds01 $dstDS new-flash-ds01 Import-Csv C:\work\ds01_inventory.csv | ForEach-Object { $vm Get-VM -Name $_.Name -ErrorAction SilentlyContinue if (-not $vm) { Write-Warning 跳过不存在的虚拟机: $($_.Name); return } Write-Host 开始迁移: $($vm.Name) try { Move-VM -VM $vm -Datastore $dstDS -DiskStorageFormat SameAsSource -Confirm:$false -ErrorAction Stop Write-Host 完成: $($vm.Name) } catch { Write-Error 迁移失败: $($vm.Name) - $($_.Exception.Message) break } } Disconnect-VIServer -Server vc01.example.com -Confirm:$false参数说明-DiskStorageFormat SameAsSource保持磁盘 Thin/Thick 属性不变-Confirm:$false跳过交互式确认这一笔由变更单的审批环节兜底不能省审批-ErrorAction Stop配合break是刻意设计的错误即中断策略——批量迁移里最怕失败三台还继续跑中断后人工定位原因再续跑比无人值守跑完更能控风险。脚本里没有加-RunAsync因为单 vCenter 并发任务超过一定数量后任务调度本身会抢占资源反而把单台迁移速度拖慢。4.3 并发度、限速与维护窗口节奏三个必须定的参数批量迁移的三个节奏控制点是并发数、任务优先级和维护窗口分段。并发数不能拍脑袋。一个集群同时跑 4~8 个 svMotion 任务是常见的安全范围同时要求任一台 ESXi 上的迁移任务不超过 2 个。判断并发是否过高的实时指标在 esxtop按u看 CPU 就绪百分比按d看存储队列深度DQLEN。DQLEN 长时间高于 32说明宿主机存储队列打满必须压并发。批量任务里可以用esxtop -b -n 3 /tmp/storage.sv做后台采样避免交互式界面占着终端。任务优先级方面Move-VM没有直接的带宽限制参数但可以调整 vCenter 任务的执行优先级。更实际的做法是按业务价值分批开发测试和批处理虚拟机先迁数据库和核心交易最后迁避免批量拷贝与业务高峰抢存储带宽。维护窗口节奏参考下表阶段内容建议时长变更前核对快照保险、容量复核、多路径确认30 分钟批量迁移按 4.2 脚本分批执行2~4 小时取决于数据量切换后抽查抽 3~5 台核心 VM 看 IO 延迟与任务状态15 分钟观察期源存储保持在线不回收空间24 小时关于快照再补一句svMotion 本身不要求打快照数据库虚拟机也不要为了迁移临时打一致性快照切换阶段短暂的 IO 停顿对数据库的影响小于一个额外快照带来的长期性能损耗。真正需要在意的兜底是备份系统的最近一次应用一致性备份而不是临时快照。5. 收尾验证与回退兜底完整方案的最后两公里5.1 源端清理与幽灵文件的边界判断svMotion 完成后源存储上通常残留空目录和.vswp交换文件这些可以等 vCenter 自动回收也可以手动清理。但有一类文件不能凭文件名判断同名 VMDK 若仍被另一台虚拟机引用删掉就是事故。上宿主机确认目录归属# 列出宿主机上正在运行的虚拟机及其所属目录 esxcli vm process list | grep -A 6 Display Name # 再查目标 VMDK 是否被占用的文件锁 vmkfstools -T /vmfs/volumes/old-ds01/webserver-01/webserver-01.vmdkvm process list输出里每个 World ID 对应的虚拟机名与文件路径如果依然指向源存储说明这台虚拟机没被迁走或迁走了但配置文件没更新属于迁移失败信号。确认所有虚拟机都不再引用源目录后把源数据存储置为维护模式走 vSphere 的正常卸载流程比手工rm安全得多。5.2 回退不能只依赖反向 svMotion在线迁移的反向操作确实只是再跑一次 svMotion但把回退方案全部押在这上面有风险如果发现问题时目标存储已经在间歇性丢 IO反向迁移同样会失败。所以迁移前就应保留一份不依赖目标存储的备份——用 vSphere Replication 把关键虚拟机复制到另一套独立存储或由备份软件做一次完整的应用一致性备份。这样即使目标存储物理故障也能用备份直接拉起服务而不是先想办法把坏盘上的虚拟机迁出来再谈恢复。5.3 迁移后 24 小时的复查清单三个命令与一个指标每次存储切换后用同一套固定动作复查结果才可对比# 确认目标 VMDK 类型与父链完整 vmkfstools -T /vmfs/volumes/new-flash-ds01/webserver-01/webserver-01.vmdk # 确认目标 LUN 多路径全部 Active esxcli storage nmp device list --device naa.6000c29e0e2f4f000000000000000000 # 用 esxtop 采样观察存储队列深度回落到 8~16 esxtop -b -n 3 | grep -E NAA|DQLEN复查的核心指标是同一时段的存储延迟对比。迁移完成后 24 小时在 vCenter 性能图表里找同规格虚拟机对比源存储与目标存储的 99 百分位延迟曲线。目标存储延迟持续高于源存储 1.5 倍且超过两小时先查多路径选路和队列深度不要急着反向迁移如果是存储固件与 ESXi HBA 驱动兼容性问题反向迁移只是换个地方踩同一个坑应该在存储侧升级固件或更换 HBA 驱动后重试。本文还有配套的精品资源点击获取
vSphere Storage vMotion实战：虚拟机在线存储迁移与批量切换指南
简介面向VMware vSphere运维与存储工程师的完整迁移方案文档以某制造业大厂虚拟化平台在线切换迁移为实例系统梳理存储迁移的规划、执行与回退全流程。资源为1个doc文件压缩包大小1.92MB内容结构清晰既可作为项目评审材料也可直接打印为现场操作手册。文档从迁移前必读入手明确适用场景和注意事项详细展开环境准备环节涵盖基础信息统计、机房布线、ESXi主机光纤卡更换、系统运行状态检查、工具准备以及目标存储RAID组与LUN规划、SAN交换机规划、数据备份等前置工作正文给出添加目标存储映射、在线迁移虚拟机、迁移后移除源存储、业务系统调测的具体操作步骤。尤其值得关注的是文档单独设置回退方案章节针对数据备份与恢复、割接失败导回等场景提供回退步骤强化迁移风险控制。已有139人学习下载适合存储替换、性能优化与容灾调整项目的技术团队参考。1. 从一次存储整列退役说起vSphere 在线存储迁移到底解决什么问题存储阵列每三到五年就要换一轮控制器到维保末期、固件不再更新或者业务要求从机械盘池整体切到全闪池。直接把虚拟机停机再拷走在今天的大厂环境里几乎不可行——数据库和消息队列断十分钟上下游对账与应用监控就会一起告警。vSphere 平台的存储在线切换迁移要解决的就是让虚拟机在持续运行状态下把 VMDK、快照链和配置文件从一个数据存储整体搬到另一个数据零丢失业务侧只感知到最后一两秒的存储 IO 抖动。落地这项能力的核心机制叫 Storage vMotion。这套方案面向虚拟化运维、存储工程师和负责维护窗口的架构师覆盖原理、前置条件、单台迁移、批量自动化与收尾验证产物是一套能直接进变更单的完整动作流程。2. Storage vMotion 的工作原理与前置条件为什么能在线又为什么不能跨集群乱迁2.1 svMotion 的读写路径全量拷贝、差量跟踪与原地址即时切换Storage vMotion 的在线不是靠快照恢复而是靠三个阶段接力。迁移启动后ESXi 会在目标数据存储上创建同规格的新 VMDK并把源盘的存量数据按块拷贝过去与此同时虚拟机照常运行新增的写请求会同时反映到源盘和目标盘的变更记录里保证两边的数据视图不分裂。拷贝接近完成时宿主机进入切换阶段短暂暂停虚拟机把增量部分补齐到目标端更新虚拟机配置文件里的磁盘路径指向然后恢复运行。整个过程虚拟机不关机guest 里不需要改任何配置SCSI 磁盘、网卡和 UUID 由 vCenter 平滑接管。理解这条路径对排错很有价值。迁移总时长由存量拷贝决定瓶颈通常在目标存储的写入吞吐或迁移流量所走网络带宽切换时长则取决于增量大小也就是拷贝期间业务产生了多少写量。大厂环境里一个常见误判是只评估磁盘容量、不评估写密度——一个单日写入 2TB、磁盘容量只有 800GB 的虚拟机增量阶段可能反复追不上迁移任务长时间停在切换中而误以为卡死。提示svMotion 的迁移数据走 vMotion 的 VMkernel 接口没有单独配置 vMotion 网络的集群流量会落到管理网络迁移速度和管理面稳定性互相影响。有条件就单独加一个 vMotion vmknic并把 MTU 统一到 9000。2.2 迁移前必须核对的环境清单版本、存储类型、网络与硬件兼容性版本上先把底线说清Storage vMotion 从 ESX 4.1 时代就有但 vSphere 6.5 之后才支持无共享存储的跨主机迁移shared-nothing svMotion6.7 到 7.0 才逐步完善跨 vCenter 迁移和加密迁移。大厂环境里最常见的组合是 vSphere 6.7/7.0/8.0 集群界面路径和命令基本一致但跨大版本集群之间做 svMotion要提前核对 EVC 模式与虚拟机兼容性。前置条件按下面这张表逐项核检查项要求核错会怎样vCenter 与 ESXi 版本源、目标集群同版本且由同一 vCenter 纳管任务直接失败或回滚目标数据存储容量大于源端总使用量加快照链总和拷贝中途报 InsufficientSpace 并回滚磁盘格式目标存储支持 Thin / Thick 中至少一种格式转换后空间翻倍不报错但容量失真存储多路径目标 LUN 的 PSP 与路径状态已核对拷贝慢或切换阶段 IO 超时网络vMotion VMkernel 接口 MTU 两端一致大数据包被丢任务反复重试虚拟机硬件版本虚拟硬件 v7 及以上界面里更改数据存储选项直接置灰多路径是这里最容易被看起来正常骗过的一项。目标存储里的 LUN 如果采用 FIXED固定路径策略主路径失效后 ESXi 切换到备用路径需要数秒这段时间的存储延迟会从毫秒级跳到秒级如果恰好撞上切换阶段虚拟机里的数据库会话可能直接中断。迁移前把目标存储的 PSP 策略、每条路径的 Active 状态都拉一遍是合情合理的变更前动作。2.3 哪些情况不能在线迁移RDM、共享 VMDK 与快照链边界第一类是物理 RDM裸设备映射。svMotion 只搬文件型 VMDK物理兼容模式的 RDM 不会出现在迁移向导中必须先转换为虚拟兼容模式或者用整盘克隆方式重新挂载。第二类是共享 VMDK典型场景是 Windows 故障转移集群里的共享仲裁盘多台虚拟机同时引用同一个 VMDK 文件svMotion 不感知共享语义迁移后锁机制可能被破坏。大厂处理这类集群盘常见做法是只迁各节点的系统盘和数据盘共享盘随集群级别整体切换。第三类是链接克隆。链接克隆的 delta 盘依赖父盘文件单独迁移克隆体而不迁父盘会导致磁盘链断裂。处理办法是迁移前做一次快照合并或者把整个克隆组连同父盘规划进同一次迁移批次。还有一类容易被忽略但在存储整列退役时必然踩到的边界如果这次迁移的最终目的是源存储彻底下线要先在集群设置里把 vSphere HA 的存储心跳数据存储从源存储上摘掉再执行迁移否则最后一台虚拟机迁走后心跳组件因找不到数据存储而反复告警整个存储退役流程会被拉长。3. 单台虚拟机在线切换的最小可复现流程从 Web Client 到 esxcli 核对3.1 Web Client 里完成一次更改数据存储的完整操作路径vCenter 的 vSphere Client 里右键虚拟机 → 迁移 → 迁移类型选仅更改存储Change storage only。第二步选择目标数据存储目标既可以是本地 VMFS也可以是 NFS 挂载卷或 vSAN 分布式存储上的数据存储随后决定磁盘格式与源相同Same format as source保留原有 Thin/Thick 属性最稳妥推荐默认。精简置备Thin Provisioned按实际使用量分配空间适合全闪且容量紧张的环境。厚置备延迟置零Lazy Zeroed预分配空间但不立即写零适合批处理类低延迟敏感业务。厚置备急切置零Eager Zeroed预分配并全盘写零vSphere 官方推荐给数据库类 IO 密集业务。第三步核对源和目标数据存储容量与网络兼容性确认后 vCenter 会创建一条重新定位虚拟机的任务。任务执行期间虚拟机保持运行业务侧只看到磁盘延迟轻微波动不需要安排业务停机。如果虚拟机挂载了多块磁盘迁移向导允许分盘指定目标——把系统盘落到全闪池、数据盘落到大容量 SATA 池这是分层存储方案里很常见的用法。这里有一个我通常会坚持的习惯磁盘格式选择与源相同不要在手术窗口里同时改磁盘属性和存储路径。等业务低峰期再用磁盘属性里的紧凑或转换为精简做一次带内格式优化比在迁移时顺手改格式更可控。3.2 用 esxcli 在 ESXi 层面确认存储设备与多路径状态迁移前在虚拟机所在宿主机上做一次存储健康核验。SSH 登录 ESXi需要先在 DCUI 或 vCenter 里开启 ESXi Shell 与 SSH 服务执行# 列出所有存储设备确认目标 LUN 的 naa 标识、容量与状态 esxcli storage core device list | grep -w naa. # 查看指定 LUN 的多路径状态Expected Paths 与 Working Paths 必须一致 esxcli storage core path list --device naa.6000c29e0e2f4f000000000000000000 # 查看 VMFS 卷与 LUN 的映射关系确认目标存储已正常挂载 esxcli storage vmfs extent list如果 Working Paths 小于 Expected Paths说明阵列端还有链路没映射到位或光纤交换机的 zone 没放完这种状态迁过去大概率慢且不稳。多路径策略用esxcli storage nmp device list查看必要时把 PSP 改为轮询模式# 查看当前 LUN 的 PSP 策略与主路径 esxcli storage nmp device list --device naa.6000c29e0e2f4f000000000000000000 # 将 FIXED 改为 ROUND_ROBIN适合绝大多数全闪阵列 esxcli storage nmp set --device naa.6000c29e0e2f4f000000000000000000 --psp VMW_PSP_RR说明这些命令不是迁移本身必需的步骤但大厂做存储切换时存储团队经常只报一句路径已配好实际是否有冗余路径、首选路径是否指向正确的控制器ESXi 侧必须自己再确认一遍。把每条路径都跑一次 path list 核对 Active能省掉迁移后一半以上的 IO 性能排查。3.3 迁移结果验证用 vmkfstools 与目录结构核对新磁盘类型任务显示完成后登录目标存储所在宿主机进入该虚拟机的数据存储目录# 查看目标目录中的文件构成VMDK、VMX、VSWP 是否齐全 ls -lh /vmfs/volumes/new-flash-ds01/webserver-01/ # 查看 VMDK 描述文件确认 diskType、createType 与容量字段 vmkfstools -T /vmfs/volumes/new-flash-ds01/webserver-01/webserver-01.vmdk # 对比源端目录确认没有同名 vmdk 残留 ls -lh /vmfs/volumes/old-ds01/webserver-01/正常输出里 diskType 为 VMFScreateType 与源端一致容量字段等于该虚拟机磁盘的标称值。如果目标目录里出现-flat.vmdk与描述性 vmdk 大小不匹配说明拷贝不完整或中途有人手工干预要立刻查看 vCenter 的任务历史。源端目录里残留的.vswp和空目录是 vSphere 清理机制延迟几分钟内会回收超过 24 小时还在且同名 vmdk 仍被某个虚拟机配置引用那多半是共享盘不要手工删除回到 vCenter 里确认磁盘映射关系后再处理。4. 批量切换的节奏控制用 PowerCLI 在一轮维护窗口内迁完一个存储池4.1 先盘存量统计源存储上的虚拟机、磁盘与快照分布一个承载几百台虚拟机的大存储池靠 Web Client 一台台点迁移既慢又容易被审计挑毛病。PowerCLI 是 vSphere 官方支持的批量管理方式安装 VMware.PowerCLI 模块后执行# 连接 vCenter域账号或本地管理员均可 Connect-VIServer -Server vc01.example.com -Protocol https # 归集源存储上的所有虚拟机并计算磁盘总量 $src Get-Datastore -Name old-ds01 $vms Get-VM -Datastore $src $vms | Select-Object Name, {NTotalDiskGB;E{[math]::Round((($_.HardDisks | Measure-Object CapacityGB -Sum).Sum), 1)}}, {NHasSnapshot;E{($_.Snapshot).Count -gt 0}} | Sort-Object TotalDiskGB -Descending | Export-Csv C:\work\ds01_inventory.csv -NoTypeInformation脚本逻辑说明Get-VM -Datastore $src按数据存储归集虚拟机Measure-Object CapacityGB统计的是虚拟磁盘的标称容量不是实际占用对 Thin 盘会偏大但这正是排迁移顺序时需要的——把标称容量大的放前面避免维护窗口被超大虚拟机占满。HasSnapshot用于筛出带快照的虚拟机带快照的迁移时间明显拉长建议单独分一批。导出的 CSV 直接贴到变更单里作为迁移顺序和审计依据。如果源存储上还躺着模板和 ISO 文件用Get-Template单独归集模板迁移不占用 svMotion 任务直接复制文件更快。4.2 批量迁移脚本按依赖分批、单个确认、错误即中断# 从清单 CSV 批量执行 svMotion保持磁盘格式不变 $srcDS old-ds01 $dstDS new-flash-ds01 Import-Csv C:\work\ds01_inventory.csv | ForEach-Object { $vm Get-VM -Name $_.Name -ErrorAction SilentlyContinue if (-not $vm) { Write-Warning 跳过不存在的虚拟机: $($_.Name); return } Write-Host 开始迁移: $($vm.Name) try { Move-VM -VM $vm -Datastore $dstDS -DiskStorageFormat SameAsSource -Confirm:$false -ErrorAction Stop Write-Host 完成: $($vm.Name) } catch { Write-Error 迁移失败: $($vm.Name) - $($_.Exception.Message) break } } Disconnect-VIServer -Server vc01.example.com -Confirm:$false参数说明-DiskStorageFormat SameAsSource保持磁盘 Thin/Thick 属性不变-Confirm:$false跳过交互式确认这一笔由变更单的审批环节兜底不能省审批-ErrorAction Stop配合break是刻意设计的错误即中断策略——批量迁移里最怕失败三台还继续跑中断后人工定位原因再续跑比无人值守跑完更能控风险。脚本里没有加-RunAsync因为单 vCenter 并发任务超过一定数量后任务调度本身会抢占资源反而把单台迁移速度拖慢。4.3 并发度、限速与维护窗口节奏三个必须定的参数批量迁移的三个节奏控制点是并发数、任务优先级和维护窗口分段。并发数不能拍脑袋。一个集群同时跑 4~8 个 svMotion 任务是常见的安全范围同时要求任一台 ESXi 上的迁移任务不超过 2 个。判断并发是否过高的实时指标在 esxtop按u看 CPU 就绪百分比按d看存储队列深度DQLEN。DQLEN 长时间高于 32说明宿主机存储队列打满必须压并发。批量任务里可以用esxtop -b -n 3 /tmp/storage.sv做后台采样避免交互式界面占着终端。任务优先级方面Move-VM没有直接的带宽限制参数但可以调整 vCenter 任务的执行优先级。更实际的做法是按业务价值分批开发测试和批处理虚拟机先迁数据库和核心交易最后迁避免批量拷贝与业务高峰抢存储带宽。维护窗口节奏参考下表阶段内容建议时长变更前核对快照保险、容量复核、多路径确认30 分钟批量迁移按 4.2 脚本分批执行2~4 小时取决于数据量切换后抽查抽 3~5 台核心 VM 看 IO 延迟与任务状态15 分钟观察期源存储保持在线不回收空间24 小时关于快照再补一句svMotion 本身不要求打快照数据库虚拟机也不要为了迁移临时打一致性快照切换阶段短暂的 IO 停顿对数据库的影响小于一个额外快照带来的长期性能损耗。真正需要在意的兜底是备份系统的最近一次应用一致性备份而不是临时快照。5. 收尾验证与回退兜底完整方案的最后两公里5.1 源端清理与幽灵文件的边界判断svMotion 完成后源存储上通常残留空目录和.vswp交换文件这些可以等 vCenter 自动回收也可以手动清理。但有一类文件不能凭文件名判断同名 VMDK 若仍被另一台虚拟机引用删掉就是事故。上宿主机确认目录归属# 列出宿主机上正在运行的虚拟机及其所属目录 esxcli vm process list | grep -A 6 Display Name # 再查目标 VMDK 是否被占用的文件锁 vmkfstools -T /vmfs/volumes/old-ds01/webserver-01/webserver-01.vmdkvm process list输出里每个 World ID 对应的虚拟机名与文件路径如果依然指向源存储说明这台虚拟机没被迁走或迁走了但配置文件没更新属于迁移失败信号。确认所有虚拟机都不再引用源目录后把源数据存储置为维护模式走 vSphere 的正常卸载流程比手工rm安全得多。5.2 回退不能只依赖反向 svMotion在线迁移的反向操作确实只是再跑一次 svMotion但把回退方案全部押在这上面有风险如果发现问题时目标存储已经在间歇性丢 IO反向迁移同样会失败。所以迁移前就应保留一份不依赖目标存储的备份——用 vSphere Replication 把关键虚拟机复制到另一套独立存储或由备份软件做一次完整的应用一致性备份。这样即使目标存储物理故障也能用备份直接拉起服务而不是先想办法把坏盘上的虚拟机迁出来再谈恢复。5.3 迁移后 24 小时的复查清单三个命令与一个指标每次存储切换后用同一套固定动作复查结果才可对比# 确认目标 VMDK 类型与父链完整 vmkfstools -T /vmfs/volumes/new-flash-ds01/webserver-01/webserver-01.vmdk # 确认目标 LUN 多路径全部 Active esxcli storage nmp device list --device naa.6000c29e0e2f4f000000000000000000 # 用 esxtop 采样观察存储队列深度回落到 8~16 esxtop -b -n 3 | grep -E NAA|DQLEN复查的核心指标是同一时段的存储延迟对比。迁移完成后 24 小时在 vCenter 性能图表里找同规格虚拟机对比源存储与目标存储的 99 百分位延迟曲线。目标存储延迟持续高于源存储 1.5 倍且超过两小时先查多路径选路和队列深度不要急着反向迁移如果是存储固件与 ESXi HBA 驱动兼容性问题反向迁移只是换个地方踩同一个坑应该在存储侧升级固件或更换 HBA 驱动后重试。本文还有配套的精品资源点击获取
