虚拟机迁移到另一台物理主机，核心思路是先确定业务中断容忍度，再选择冷迁移或热迁移方案，最后按虚拟化平台执行对应操作。迁移本身并不复杂，复杂的是迁移前的评估和迁移后的验证，下面直接拆解不同场景下的操作路径。
虚拟机迁移到另一台物理主机，冷迁移和热迁移怎么选？
迁移方式的选择完全由业务属性决定。 如果这台虚拟机跑着生产数据库或核心业务系统，停机五分钟都会引发投诉，那就必须走热迁移路线，如果只是测试环境、开发机，或者你本身就计划维护窗口，冷迁移反而更省事。
冷迁移：关机拷贝，最稳妥也最慢
冷迁移的逻辑很简单：先把虚拟机关机，把磁盘文件复制到新物理主机，再重新注册启动。 整个过程虚拟机处于停机状态，所以叫冷迁移。
- 适用场景：计划内维护、测试环境搬迁、物理机下架替换。
- 优点：操作简单，兼容性风险低，几乎不会出现迁移后启动失败的问题。
- 缺点：业务中断时间=关机时间+拷贝时间+启动时间，数据量越大，中断越久。
操作路径一般是：登录旧物理机的虚拟化管理平台，把虚拟机关机，然后导出或复制虚拟机磁盘文件（比如VMware的VMDK文件、Hyper-V的VHDX文件），通过网络或移动硬盘传到新物理机，再用导入功能注册虚拟机，最后开机验证。如果你对命令行熟悉，用scp或rsync传大文件会比平台自带的导出功能快得多。
热迁移：业务不中断，但环境要求苛刻
热迁移的核心机制是将虚拟机内存状态实时同步到目标物理主机，最终在用户无感知的情况下完成切换，以VMware vMotion为例，源主机和目标主机必须满足一堆前提条件才能跑通。
行业共识认为,热迁移最关键的三个前提是：CPU型号兼容、共享存储可用、网络带宽充足。 尤其是CPU，如果两台物理机的CPU代际差异过大，vMotion会直接报错，解决办法是开启EVC模式（增强型vMotion兼容性），让集群内的CPU指令集统一到同一水平线。
热迁移的操作路径相对固定：
- 在vCenter中选中虚拟机,右键选择“迁移”。
- 选择“仅更改计算资源”（只换物理机，不换存储）或“更改计算资源和存储”。
- 系统自动检查兼容性,通过后开始迁移。
- 迁移过程中虚拟机持续运行,完成后你会看到虚拟机已经跑在新物理主机上。
VMware虚拟机迁移到新物理主机的实操步骤
VMware是市场份额最大的虚拟化平台,所以单独拎出来讲，这里分两种情况：有vCenter的和没有vCenter的。
有vCenter：用vMotion做热迁移
前提条件检查清单如下：
- 源和目标物理主机加入同一个集群,且开启EVC或CPU型号一致。
- 使用共享存储（如光纤SAN、iSCSI存储或NFS存储）。
- 物理主机网络互通,建议万兆网络，千兆网络在大内存虚拟机迁移时容易超时。
- 目标主机资源足够,内存、CPU、存储空间都要有冗余。
操作路径：登录vCenter Web客户端，在清单里找到目标虚拟机，右键选择“迁移”，按向导提示选择目标主机，保持存储不变，系统自动执行，迁移过程中，你可以在任务栏看到进度条，虚拟机业务完全不受影响。
没有vCenter许可证：导出OVF再导入
很多中小环境只用ESXi单机版,没有vCenter，此时vMotion不可用，只能用冷迁移的方式：
- 在旧ESXi主机上,右键虚拟机，选择“导出OVF模板”。
- 导出完成后,用vSphere客户端连接新物理主机。
- 选择“部署OVF模板”，指向之前导出的文件，按向导完成导入。
- 导入后检查虚拟机配置（CPU核数、内存、网卡），然后开机验证。
这种方式适合虚拟机数量少、数据量在几十GB级别的场景。 如果虚拟机磁盘超过几百GB，导出OVF会非常耗时，不如直接在底层把VMDK文件拷贝到新主机的数据存储，再用“注册虚拟机”功能挂载。
Hyper-V虚拟机迁移到另一台物理机的两条路
微软生态下的Hyper-V迁移逻辑和VMware不同，主要体现在实时迁移和存储迁移的耦合方式上。
实时迁移：不用关机，但需要故障转移集群或Hyper-V主机共同加入域环境
Hyper-V的实时迁移在Windows Server 2012之后变得非常成熟，可以做到不依赖共享存储，直接把虚拟机从一台物理机搬到另一台物理机。
操作路径：
- 在两台Hyper-V主机上打开“故障转移集群管理器”。
- 创建一个集群,把两台物理机加进去。
- 在集群中找到虚拟机,右键选择“实时迁移”，选择目标节点。
- 系统会复制虚拟机内存和磁盘状态,完成切换。
副本迁移：异步复制，适合跨机房场景
如果两台物理机不在同一个机房,实时迁移就别想了，网络延迟和带宽撑不住，此时用
Hyper-V副本（Replica）更实际，副本迁移的本质是把虚拟机磁盘异步复制到目标主机，源主机继续运行，等复制完成后做一次计划内故障转移。
| 对比维度 | 实时迁移 | 副本迁移 |
|---|---|---|
| 业务中断 | 无感知 | 切换时有短暂中断 |
| 网络要求 | 低延迟内网 | 普通广域网即可 |
| 复制机制 | 内存+磁盘同步 | 磁盘异步复制 |
| 适用场景 | 同机房负载均衡 | 灾备、跨机房搬迁 |
虚拟机迁移前必须检查的六件事
迁移失败多半不是操作问题,而是准备工作没做到位，下面这些项目建议逐条核对。
- 磁盘空间：目标物理机的数据存储空间必须大于虚拟机当前磁盘占用，注意，如果虚拟机内部有大量空闲空间但磁盘文件没有收缩，你需要的空间是文件实际大小，不是系统里显示的已用空间。
- 网络配置：如果迁移后虚拟机网卡对应的端口组或虚拟交换机名称不一致，会导致虚拟机启动后没有网络，提前记好虚拟机IP、掩码、网关、DNS。
- 硬件兼容性：VMware里检查虚拟机的硬件版本是否被目标ESXi主机支持，老版本虚拟机迁移到新平台通常没问题，但新版本虚拟机迁移到老平台会直接失败。
- 许可证绑定：部分软件的授权和CPU核数、物理机硬件信息绑定，迁移后可能需要重新激活，Windows Server和SQL Server尤其要注意。
- 备份：迁移前做一次完整备份，或者至少拍一个快照，快照是迁移失败后的后悔药，别省这一步。
- 业务低峰期：就算热迁移业务不中断，迁移过程中存储IO会暴涨，对同存储上的其他虚拟机有性能冲击，选在业务低峰期操作，是运维的基本素养。
虚拟机迁移后验证与故障排查
迁移完成不代表结束,验证环节漏了，后面会出大问题。
迁移后的验证清单
- 虚拟机能否正常开机,开机时间是否异常。
- 系统内部查看IP配置是否生效,能否ping通网关。
- 业务系统的服务是否全部启动,日志里有没有报错。
- 如果迁移涉及存储变更,检查磁盘读写性能是否达标。
- 确认虚拟机已经运行在目标物理主机上,源主机上的旧文件可以清理。
常见失败原因及对策
- 迁移过程中网络中断：表现为迁移任务卡住或超时，对策：检查物理交换机端口配置，确认链路聚合和MTU设置一致。
- CPU不兼容报错：vMotion直接拒绝执行，对策：在两台物理机上启用EVC模式，选择较低的CPU代际作为基准。
- 虚拟机启动后蓝屏：大概率是磁盘控制器类型变了，VMware的SCSI控制器和Hyper-V的SCSI控制器驱动不同，迁移前在虚拟机内预装对应虚拟化平台的驱动。
- 迁移后性能变差：检查新物理主机的CPU主频、内存通道数、存储类型是否弱于旧主机，不少情况下，问题出在目标主机的存储走的是网络存储，延迟比本地盘高了一个量级。
虚拟机迁移到另一台物理主机常见问题解答
虚拟机迁移需要多久？
取决于数据量大小、网络带宽、存储介质速度三方面，一台几十GB的虚拟机在千兆内网下冷迁移，耗时大概在十几分钟到半小时；热迁移因为需要同步内存和磁盘状态，时间会略长，但业务不中断，如果虚拟机数据量达到TB级别，建议用物理拷贝硬盘的方式，比网络传输快得多。
迁移过程中业务会中断吗？
冷迁移必然中断,中断时间就是关机到开机之间的全部时长，热迁移理论上是零中断，但切换瞬间会有毫秒级抖动，对实时性要求极高的应用（比如证券交易系统）建议选择业务低峰期操作，据VMware官方文档，vMotion的切换时间通常控制在2秒以内，但网络质量差时可能更长。
迁移后IP地址会变吗？
默认情况下,虚拟机的IP地址是配置在虚拟机操作系统内部的，迁移只是换了物理宿主机，网卡配置不变，IP就不会变，但要注意，如果新物理机的虚拟交换机名称或端口组和旧主机不一致，虚拟机网卡可能无法正常连接，导致IP配置丢失，迁移前确认端口组名称完全一致即可避免这个问题。
虚拟机迁移这件事,说到底是把虚拟机的计算、存储、网络三个维度的状态从一台物理机搬到另一台物理机，冷迁移适合小规模、可停机的场景，热迁移适合生产环境但依赖基础设施质量，无论选哪条路，迁移前的检查清单和迁移后的验证步骤缺一不可，按照上面的操作路径走，至少能避开九成以上的坑。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/618322.html
