1. 迁移前的认知与选型
1.1 迁移到底在解决什么问题
做OpenStack平台运维的人，几乎都会遇到这样的场景：某台计算节点要下线维护，或者某台宿主机负载告警，甚至只是单纯想调整资源分布，这时候你就需要把上面的云主机实例挪走。Migrate Instance 就是干这件事的。它本质上是把一台宿主机上的虚拟机，在不中断业务（或者短暂中断）的前提下，移动到另一台宿主机上继续运行。
我在实际维护中，用到迁移最多的是两类场景，一类是宿主机维护，比如升级内核、更换硬件、修复RAID，这种物理层面的操作必须让实例先跑路；另一类是资源重平衡，某个节点CPU或者内存被打满，而另外几个节点闲得慌，手工迁移几台实例过去，比触发自动伸缩更可控。还有一类不算高频但很头疼的，就是宿主机出现硬件异常征兆，比如反复报EDAC错误、磁盘出现大量坏道，这时候立刻迁移实例是降低故障影响面的有效手段。
在动手之前必须要清醒一点：迁移这个动作本身是有风险的。网络闪断、磁盘IO阻塞、CPU兼容性问题、内存脏页速率过高，任何一个环节出问题都会造成迁移失败甚至实例异常。我在早期管理OpenStack集群时，对迁移这件事掉以轻心，结果吃过不小的亏——一台负载很高的实例在做热迁移时卡住，目标主机上的实例启动后网络不通，来回排查了很久才发现是网卡中断绑核问题和CPU型号不一致导致的。所以这篇内容，我会把迁移的底层原理和实际操作结合起来讲，尽量把每一个可能踩坑的环节都说明白。
1.2 冷迁移和热迁移，到底怎么选
迁移在OpenStack体系里大体分为两类：冷迁移和热迁移（也叫在线迁移）。
**冷迁移（Cold Migration / Migrate）**通常指nova migrate命令触发的迁移。这个过程会先把实例关机（或者保持关机状态），把磁盘数据复制到目标宿主机，然后在目标宿主机上重新启动实例。如果实例当时是运行中的，nova服务会先做一次优雅关机（默认走ACPI shutdown），等实例彻底停止后再搬运数据。冷迁移期间业务中断是必然的，但胜在逻辑简单、稳定性高，对底层硬件环境的要求也比较宽松。
**热迁移（Live Migration）**对应的是nova live-migration命令。它不需要关机，通过libvirt在源主机和目标主机之间同步内存状态和磁盘变更，业务几乎无感知。这个听起来很美好，但实际对条件的要求相当苛刻：需要共享存储或者块迁移支持，需要源目标主机CPU指令集兼容，需要网络带宽充足，还需要nova和libvirt版本配合到位。任何一个条件不满足，热迁移要么根本起不来，要么跑到一半就失败。
在选型上我个人的习惯是这样的：能接受短时间中断的内部业务系统，优先用冷迁移，省心；核心生产业务、不允许中断的实例，优先热迁移，但必须在迁移窗口做充分预检。不要为了炫技强行热迁移，有些老旧的实例镜像、特殊的直通设备场景，冷迁移反而是更稳的选择。
2. 核心逻辑：nova是怎么完成一次迁移的
2.1 从命令行到虚拟机重建的完整链条
要把迁移操作做好，你得先知道背后发生了什么。这里我以冷迁移为例完整拆解一遍各组件之间的协作流程。
当你执行openstack server migrate <instance>之后，请求会先到达nova-api，经过Keystone鉴权和quota检查之后，nova-api把请求写入消息队列。nova-conductor从队列中取出这个迁移请求，开始走调度逻辑——它要去数据库里查实例当前的host、节点信息，然后调用nova-scheduler做过滤和权重计算，选出一个可以放置的目标节点。这里有个容易被忽略的细节：nova-conductor在做冷迁移调度时，默认会把实例当前所在的源节点排除掉，这个行为由allow_resize_to_same_host参数控制，如果该参数没有显式开启，你是没法把实例迁移回原主机的。
目标节点选定之后，nova-conductor发送消息给目标节点上的nova-compute，让它准备接收实例。目标节点的nova-compute会创建实例的基础目录（/var/lib/nova/instances/<instance_uuid>/），然后从镜像服务或者快照中准备系统盘。如果是块迁移（block migration）的场景，数据这块会有不同的处理方式，这个下面细说。
等数据到位之后，目标节点的nova-compute通过libvirt定义虚拟机的XML配置，开始启动实例。启动成功后，nova-compute上报状态到数据库，nova-conductor更新instance的host、node字段，同时通知源节点上的nova-compute清理本地实例数据。整个流程走完，你会在nova list里看到实例的host已经变了。
整个链路中消息队列起到异步解耦的作用，所以你在命令行敲完迁移指令，响应返回快不代表迁移完成。一定要用nova migration-list或者openstack server migration list去跟踪迁移状态。
2.2 热迁移背后的数据同步机制
热迁移比冷迁移复杂的地方在于，它要一边保持源实例运行，一边把数据同步到目标。libvirt底层通过QEMU的迁移机制来实现，过程中会把源实例的内存页、CPU状态、设备状态序列化传输到目标QEMU进程。
这里有个很重要的阶段叫预拷贝（Pre-copy）。第一次先把全部内存数据传过去，之后持续迭代传输那些在上一轮传输期间被写脏的内存页。跑得快的场景下，几轮迭代后脏页速率降下来了，就进入**停机拷贝（Stop-and-copy）**阶段，短暂挂起源实例，把所有剩余内存状态和CPU状态一次性传过去，然后目标实例接管，源实例被销毁。
需要注意，如果实例内存太大，或者内存写入速率特别快——比如跑着大型数据库或者高并发缓存——脏页产生速度可能赶不上传输速度，那就进入无限循环，迁移永远无法收敛，最后libvirt会强制中止迁移。平时很多号称“迁移失败”的故障，其实根本不是网络不通，而是内存脏页速率过高导致迭代无法收敛。这个在实战排查里非常关键。
磁盘数据处理有两条路线：如果用了共享存储（比如Ceph、NFS、LVM共享卷），磁盘文件本身就在目标主机上可见，不需要额外拷贝，只要同步内存就完事；如果没有共享存储，只能用块迁移（block migration），libvirt会在迁移过程中把源实例的磁盘全部复制到目标主机，同时持续处理新写入的块数据。这种情况下，磁盘越大、数据变化越快，迁移时间越长，网络和磁盘IO的压力也越大。
3. 实操准备：迁移前必做的检查清单
3.1 计算节点资源和网络状况体检
我每次做批量迁移，都会提前半天把涉及的主机全面体检一遍。这个体检不是随便看一眼load average，而是要落到实处：
先看CPU。用virsh capabilities查看宿主机CPU的型号和特性集，对比源主机和目标主机的输出，确保QEMU能支撑的CPU模型是兼容的。如果源和目标不在同一代CPU架构上，热迁移可能会直接报target CPU does not match之类的错误。解决思路要么给实例设置明确的CPU模型，要么在nova-compute配置里开启cpu_mode = host-model，让虚拟机的CPU模型跟随宿主机，再用libvirt的CPU热插拔兼容策略做兜底。
再看内存和磁盘。free -g看物理内存余量，df -h看实例存储目录的空间余量。这里有个容易被忽视的点，冷迁移的块迁移模式下，目标主机的存储空间需求是源实例磁盘的实际用量，而不是虚拟磁盘的分配大小。如果你用du -sh /var/lib/nova/instances/<instance_uuid>/这个命令查看，才能看到真实占用。我就碰到过一次裸金属规格的实例，虚拟磁盘定义是200GB，实际数据只有20GB，但是目标主机剩余空间只有30GB，按分配大小去判断空间不够，按实际用量却刚刚好，结果没查清楚差点误判。
网络方面，重点看节点之间的带宽和质量。迁移数据走的是管理网络还是存储网络，不同架构不一样，但最好确认源和目标主机之间能直接互通，且防火墙没有拦截libvirt的迁移端口（默认是TCP 49152到49215这个段）。还要检查Open vSwitch或者Linux Bridge的配置在目标是正确的，同一个实例的安全组规则和网络端口在目标主机上能够正常映射。
3.2 实例自身状态和配置约束
不是每个实例都适合迁移。直通了PCI设备的实例（比如GPU透传、SR-IOV网卡），大部分版本OpenStack默认禁止热迁移，这是出于设备状态无法迁移的考虑。如果确定要迁，只能走冷迁移，并且要确保目标主机有同样的PCI设备可直通。
还有一类特殊情况是实例有本地磁盘。如果实例使用了ephemeral磁盘并且没有共享存储支持，就必须依赖块迁移。块迁移对后端驱动有要求，libvirt的qemu驱动基本都支持，但如果你用的是比较老旧的libvirt版本，或者使用了非标准存储后端，有可能触发未实现的BUG。碰到这种情况，我的建议是不要死磕块迁移，直接把实例做成镜像或者快照，再在目标节点上重建，反而更省事。
安全组和浮动IP也要检查。迁移本质上不会修改实例的网络拓扑，浮动IP还是绑定在原instance上，不会因为换主机而变化。但如果你用的是基于主机名或者主机IP的内部通信架构，迁移后可能会因为IP变化导致依赖它的服务全部需要重连。这点在微服务架构里尤其要提前评估，迁移窗口尽量选在业务低峰期。
最后，看实例当前状态。openstack server show <instance>里的OS-EXT-STS:power_state如果是RUNNING，冷迁移会走关机流程；如果是SHUTOFF，迁移只是搬运数据。注意，如果实例是SHELVED状态，迁移前要先unshelve，否则nova会直接拒绝操作。
4. 实操过程：从冷迁移到热迁移的命令级演示
4.1 冷迁移：标准操作流程与参数选择
假设环境是Ocata及以上版本，可直接用OpenStackClient的命令行。先确认实例基本信息：
openstack server show test-vm-001输出里重点看properties里的host、status、OS-EXT-STS:power_state这些字段。确认无误后执行冷迁移：
openstack server migrate test-vm-001 --wait加了--wait参数，命令会阻塞等待迁移完成，返回...直到看到状态更新为ACTIVE或SHUTOFF。不加--wait则立即返回，你需要自己轮询迁移状态：
openstack server migration list --server test-vm-001输出里有一列Status，正常流程为queued->preparing->migrating->post-migrating->done。如果看到error，就要进入排查流程了。
冷迁移默认行为是什么？说起来有点绕：openstack server migrate在nova里对应的操作是resize，它会把实例调度到新主机并执行“重新创建”过程。默认情况下，它不会复制本地磁盘，所以如果实例没有共享存储，命令实际会报错或者实例在目标主机无法启动。你必须显式加上块迁移参数：
openstack server migrate test-vm-001 --block-migrate --wait--block-migrate这个参数就是告诉nova：把本地磁盘数据也搬过去。如果你的实例后端存储是Ceph或者NFS这类共享存储，那么不加--block-migrate反而更快，因为数据不需要拷贝，只是改一下数据库里的host字段。
还有第三个冷迁移参数容易被忽略，叫--instance-disks-overcommit，配合--block-migrate使用。它表示在调度计算目标主机磁盘占用时，按实例虚拟磁盘的分配大小去算，而不是按实际占用去算。默认情况下nova的调度是按实际配额去评估的，开了这个参数，会让调度器认为实例会占满整个虚拟磁盘大小，从而避免把实例放到一个“实际空间够，但按分配大小不够”的主机上。
冷迁移完成后，我一般会做三件事：第一，登录实例确认业务正常；第二，openstack server show test-vm-001确认host已变化；第三，检查网络连通性和浮动IP绑定状态。确认无误后再去清理源节点上遗留的旧数据。正常情况下nova会自动清理，但偶尔会出现清理失败的情况，你会在源节点的/var/lib/nova/instances/下看到残留目录，确认无引用后手动删除即可。
4.2 热迁移：在线迁移的关键命令与手段
热迁移命令更直接：
openstack server migrate test-vm-001 --live --wait等等，这个写法在老的OpenStackClient版本里是不可用的，只有在新版本中openstack server migrate支持--live参数。在大多数生产环境里还在用旧命令的不少，所以更通用的写法是：
openstack server migrate test-vm-001 --live-migration --wait或者直接用nova命令：
nova live-migration test-vm-001三种写法本质上都调用同一个API，但参数行为不太一样。--live-migration默认走共享存储（即不拷贝磁盘）；如果是非共享存储，需要加--block-migrate参数：
openstack server migrate test-vm-001 --live --block-migrate --wait热迁移过程会持续一段时间，期间你可以开另一个终端观察迁移进度：
nova migration-list --instance-uuid <uuid>列表里能看到源主机和目标主机，以及迁移任务的状态。对于热迁移来说，状态流转和冷迁移基本一致，但在migrating阶段停留的时间长得多，因为内存传输需要时间。
热迁移过程中如果压力太大，想尽一切办法保住业务，可以考虑临时降低实例内存写入压力。比如业务方把批处理任务暂停、关闭大的分析任务、收缩缓存，让脏页速率降下来，迁移就能更快收敛。这种“治标不治本”的操作，在紧急恢复场景里很管用。
还有一个所有生产环境都必须知道的自定义迁移命令——强制迁移到指定主机。在部分故障场景下，自动调度选出的目标节点不理想，你想手动指定目标节点。冷迁移里可以这么干：先配置nova的allow_resize_to_same_host无关，它主要是限制同主机的，手动指定主机其实是靠forced_host参数。用OpenStack API的方式是调用servers.py里的_action_resize并且传入host，在OpenStackClient里目前没有优雅的命令参数那么直接，但你用nova命令时会发现它支持--host选项：
nova migrate --host target-host-02 test-vm-001nova migrate的--host选项目前在很多发行版仍然有效。不过要注意，老版本的nova并不支持在resize操作中强制指定目标主机，新版本部分支持，具体看你平台的版本。如果官方命令行不支持，你有两个变通思路：一是临时把其他候选节点禁用（nova service-disable）只留目标节点，逼调度器选中目标；二是通过API调用直接改OS-EXT-SRV-ATTR:host，但我不推荐直接改数据库，太危险。
5. 常见问题与排查技巧实录
5.1 迁移失败场景与日志定位
迁移失败是家常便饭，关键是你要知道去哪里看日志。大体日志分布是这样的：nova-conductor.log记录调度和迁移状态流转，nova-scheduler.log记录过滤和权重计算的细节，nova-compute.log记录本节点上所有虚拟机的创建和迁移操作，libvirt/qemu日志在/var/log/libvirt/qemu/<instance_uuid>.log下，能告诉你QEMU级别的具体错误。
实际中我遇到最多的一类报错是：
Live migration failed: internal error: process exited while connecting to monitor这种通常不是QEMU的问题，而是目标主机的libvirt连接问题。检查目标主机libvirtd服务是否正常、TCP端口是否可达、SELinux/AppArmor是否放行。有些系统上nova-compute没有权限访问libvirt的socket，也会出现类似情况。解决方法就是确保nova-compute用户对/var/run/libvirt/libvirt-sock有访问权限。
第二类高频率报错是CPU不兼容：
Target CPU does not provide the required features这个属于硬约束，不可强行迁移。解决的临时手段是修改实例的hw_cpu_model为兼容型号后重启实例，再尝试迁移；长期手段是规划好计算节点分组，让相同CPU型号的机器在同一个主机聚合组里，并且配置nova的cpu_shared_set或者用host aggregate的cpu_model做匹配。还有一种思路是全局打开libvirt的cpu_mode=host-model，但要注意这样做之后每台主机的CPU特性会稍微暴露给客户机，有一定风险。
第三类是经典的热迁移无限循环：
Migration is stuck for a long time due to memory pressure这种从日志上看可能没有任何报错，但迁移卡在migrating阶段几个小时不动。你需要到源主机用virsh migrate --live --verbose手动测试，或者用virsh domjobinfo <instance>查看迁移进度。如果发现memory processed和memory remaining差值一直很大，说明脏页速率太高了。处理手段前面已经说过：降低业务压力、增加网络带宽、调整QEMU迁移参数（比如增大migrate-cache-size、调整downtime-limit、开启multifd）。
5.2 迁移完成后的隐性坑
迁移“成功”不等于万事大吉，有几个隐性坑我是在实战中栽过跟头之后才整理出来的。
第一个是迁移后网络流量方向不对。这个情况在做VM直接迁移到另一个二层网络节点时容易出现。nova的自动化网络配置一般会把端口绑定到新主机，但如果你用的是手动配置的Linux Bridge，或者OVS流表没有被正确刷新，目标主机上新启动的实例可能还在用旧的网关信息，导致外部访问异常。排查手段是登录实例检查网卡配置，再到宿主机上brctl show或者ovs-vsctl show看端口绑定状态。
第二个是NFS共享存储的缓存不一致。如果你的共享存储是NFS，并且启用了一些NFS客户端的cache功能，迁移后源主机对同一份文件系统的缓存可能还没释放，会导致文件锁问题，尤其数据库这类对文件锁敏感的应用。最稳妥的做法是迁移前通知业务方做一次优雅停止，有条件的话直接做数据库在线备份，宁可做双保险。
第三个坑是CPU和内存的QoS参数丢失。老版本nova在迁移时，如果实例定义了quota或QoS规格，迁移后部分参数可能没同步到目标节点的flavor匹配上，导致CPU绑定或者内存预留失效。处理办法是迁移完成后跑一遍openstack server show，核对之前的规格，重点看hw:cpu_policy、hw:mem_page_size这些extra specs，再用virsh vcpupin或virsh memtune对比确认。
6. 避坑心得与效率建议
6.1 批量迁移的节奏控制
单个实例迁移不算复杂，批量迁移才是真正考验人的环节。我有一个坚持了很久的原则：同时迁移的实例数限制在宿主机CPU核数的一半以内，并且每批次之间等待至少10分钟。这个节奏不是凭感觉定的，一方面是要给nova-conductor和libvirt留出处理余量，另一方面是不要在故障发生时把多个实例同时搞挂。
批量迁移还有一种策略很实用，叫“滚动迁移”。把所有实例分成几组，每组先迁移一两台验证目标节点正常，再批量跟进。源节点上只保留最后几台实例，等前几台在目标节点稳定运行了，再迁最后的。这样即使目标节点有问题，影响面也只在一个批次内。
6.2 权限控制与操作审计
在多团队共用一套OpenStack的环境里，迁移权限要控制好。不是所有人都能对任意实例执行迁移操作，尤其是热迁移这种可能影响业务连续性的动作。我的建议是在Keystone里单独建一个migration_admin角色，只给负责基础设施的同事授权，业务团队有迁移需求必须走工单流程。这样出了问题可以随时审计是谁在什么时间迁了哪台实例。
审计方面，除了sar、systemd journal这些基础记录，也可以定期用API收集迁移历史。在这里我总是会在月末巡检时跑一遍所有实例的迁移记录，看有没有异常的高频迁移。如果发现某台实例经常被迁移来迁去，通常是调度策略有问题或者节点负载不稳定，需要提前治理。
6.3 从迁移到容灾：更高阶的延伸
迁移做熟了以后，可以把思维再往外延展一下。比如OpenStack本身就提供了基于cinder的卷迁移能力，以及基于openstack server rebuild的故障恢复能力。在做容灾方案时，迁移是你最常用的武器，但不能把它当成唯一方案。真正的容灾需要组合使用：实例快照定期备份到不同AZ、数据库主从复制跨节点、关键业务配置自动故障转移。
我在管理过的一个集群里，除了常规的主机维护迁移，还会每季度做一次“演练迁移”——故意模拟一个节点彻底失效，在这个节点上的所有实例能不能在目标节点顺利拉起。这个演练会暴露很多参数配置问题，比如实例依赖的镜像还在源节点本地而没放进统一镜像服务、或者某些自定义配置没有打进config drive。多演练几次之后，你会发现整个平台的健壮性上了一个台阶。
迁移动手之前，记得先想清楚一个原则：能共享存储就别搞本地盘，能热迁移就别动冷迁移，能批量滚动就别一窝蜂上。技术方案的选型比具体执行更考验功底。做运维最怕的不是迁移失败，而是从来不敢迁移——真的到了故障要来临才临时抱佛脚，那时候手忙脚乱带来的风险会成倍放大。迁移这件事，平时多练、多演、多总结，真正上战场时才不会慌。
