凌晨两点机房的集中告警平台推了一条红色告警某台计算节点的RAID控制器日志连续报错硬盘出现大量扇区重映射。值班手册上的处置意见很明确——把这台节点上的12台云主机全部迁走。那一夜我最依赖的操作就是 OpenStack Nova 的 Migrate Instance。Migrate Instance 一句话概括就是让一台虚拟机实例从当前计算节点平滑或停机地挪到另一台计算节点上。它解决的是“计算资源的再分配”问题比如硬件要维护、节点负载过高、某台宿主要退役都需要把上面的实例请出去。这篇文章我会把 Migrate Instance 从原理、前置条件、完整操作流程到排错经验完整过一遍。适合刚接手 OpenStack 环境的运维工程师也适合做虚拟化平台选型对比的同行参考。1. 为什么需要迁移实例四个真实场景与一条边界我们在生产环境里谈迁移很少是“闲着没事想搬个家”背后基本都对应着具体的运维压力。搞清楚这些场景你才知道该用冷迁移还是热迁移也才能在变更单上把理由写清楚。1.1 运维里最高频的四个迁移需求第一类是计划内硬件维护。比如某台计算节点要换内存、升级固件、清理风扇宿主机必须关机或重启。这时候实例留在本机就是等死必须迁走。能接受停机时间的用冷迁移完全不能断业务的用热迁移。第二类是宿主机资源失衡。我见过不少环境因为早期调度策略不严谨一台宿主机内存用了90%旁边一台才30%。CPU steal 指标一路上涨虚拟机里的业务开始变慢。这种时候把重负载实例往闲节点上挪是最快的止血手段。第三类是集群整合与节点退役。公有云或私有云建设初期采购的服务器性能参差。老一批机器性能弱、故障率高要把它们从计算池里摘出去实例自然要整体搬到新节点上。第四类是故障疏散。节点本身没有完全宕机但存储卡、网卡、电源等关键部件已经出现硬件预警。运维评估后决定不等它彻底挂掉提前把实例全部迁移走。这是最高级、也最考验操作熟练度的一种场景。1.2 Migrate 与 evacuate一条命令之外的分界线很多人刚接触 OpenStack 时会把迁移和疏散搞混。我在排障时经常看到同事对一台活着的节点执行 evacuate结果实例直接重建、业务中断场面非常难看。简单区分一下migrate 系列是“优雅迁移”它要求源节点还活着Nova 能和它正常通信evacuate 是“灾难重建”节点已经宕机或者完全不可用时把实例从故障节点上重新拉起来。前者尽量保留运行状态后者只能保证磁盘数据最大程度不丢内存数据基本保不住。所以迁移前你先要问自己一句这台节点还能不能正常响应 API能考虑 migrate 或 live-migrate不能走 evacuate。这个判断错了后续所有操作全是拧着来的。2. 冷迁移与热迁移的底层逻辑明白了场景就得理解动作本身。很多人把 OpenStack 的迁移想成一个“复制粘贴”动作实际上冷迁移和热迁移在底层完全是两套不同的机制踩坑的点也不一样。2.1 冷迁移关、拷、启的三段式冷迁移Cold Migration的执行路径非常直白Nova 拿到迁移请求后做三件事调用 libvirt 把实例关掉shutdown相当于给虚拟机发送 ACPI 关机信号弹不掉的会强制断电处理数据。如果实例磁盘在共享存储上数据本身不用搬目标节点直接读取同一份磁盘如果实例磁盘在本地则需要通过块迁移方式把整个磁盘镜像复制到目标节点在目标节点上重新启动实例。冷迁移期间业务是中断的。这个“断”不是几秒钟而是从关机到目标节点启动完成的全过程可能几分钟甚至更久。所以冷迁移适合可接受停机的业务比如测试环境、定时任务型应用、非核心的 Web 服务。冷迁移的优势是可靠。它不依赖内存同步不要求 CPU 型号完全一致只要目标节点资源和虚拟化环境没问题基本都能成功。缺点也明确停机时间不可控。尤其当本地盘很大、网络拷贝速度慢的时候一个 500GB 磁盘的实例迁一次可能让你等一上午。2.2 热迁移一场内存接力赛热迁移Live Migration就不一样了它的核心诉求是“业务不中断”。底层原理借用的是 libvirt/QEMU 的 live migration 能力简单说就是一场内存接力赛第一阶段把实例当前的全量内存页从源节点拷贝到目标节点第二阶段业务还在跑内存里的数据一直在变源节点要把这些变化的“脏页”再拷贝过去第三阶段如果脏页越来越少说明两边内存状态快要一致了这时在极短时间窗口内通常几十到几百毫秒暂停虚拟机把 CPU 寄存器、设备状态等最后一批数据同步过去然后立刻在目标节点恢复运行。这个“停机时间”做得好可以控制在 1 秒以内业务几乎无感。但注意热迁移不是无条件能成功的。如果虚拟机内存写入非常频繁典型如高负载数据库脏页生成速度可能永远追不上拷贝速度迁移就会一直卡住。Nova 提供了两个参数兜底自动降速auto-converge和后拷贝post-copy。前者在内存不收敛时主动限制虚拟机的 CPU让脏页速度降下来后者先让目标节点跑起来再从源节点慢慢拉取剩余内存页。后拷贝只建议在极端情况下用因为迁移一旦断掉两边状态都可能不完整。2.3 共享存储与本地盘决定迁移成败的架构分水岭存储架构直接决定了迁移的复杂度。我习惯把这部分当做一个分水岭来看存储方式冷迁移复杂度热迁移复杂度关键依赖共享存储Ceph RBD / NFS低只传元数据低只传内存状态两节点都能访问同一份数据本地盘中高需块迁移复制磁盘高内存磁盘双拷贝网络带宽、磁盘吞吐做过 VMware 的同行也别觉得陌生vMotion 和 OpenStack 的 live-migrate 本质是同一件事。区别在于 vMotion 把底层收敛得比较好OpenStack 的 live-migrate 更“裸”很多细节需要运维自己把控。尤其是本地盘的热迁移一边同步内存一边复制磁盘镜像对网络带宽和宿主机磁盘 IO 的压力非常大。我见过有同行在万兆网卡和机械盘组合的环境下做块迁移迁移过程直接把宿主机的 IO 打满连监控都告警了。所以在生产环境我强烈建议优先规划共享存储。Ceph RBD 做云平台后端不止是省心更大的价值在于迁移、快照、容灾这些日常运维动作都会简单得多。3. 迁移前必须过一遍的检查清单很多迁移失败都是“前置条件没查就动手”。OpenStack 不像某些商业虚拟化平台那样把约束条件藏得很深它反而把选择权都交给了运维。你自己不查踩雷了别怪平台。3.1 目标节点的资源与调度约束迁移本质上是重新调度。Nova 会把目标主机筛选交给 scheduler 组件所以第一步一定要确认目标节点不仅活着而且资源充足。需要看的资源有三个CPU、内存、磁盘。内存尤其重要热迁移的目标节点需要预留足够内存来装下整个实例的内存镜像。命令层面先确认服务状态openstack compute service list看到 nova-compute 状态是 enabled 且 up再检查目标节点的具体资源剩余情况openstack host show 目标节点主机名这个命令能显示该节点的 CPU、内存等资源总量和已用情况。经验值是目标节点剩余内存至少要比待迁移实例的内存配额多 20%否则即使迁移动作完成了实例跑起来也可能因为宿主机内存压力触发了内核 OOM。还有一类容易忽略的约束是聚合组aggregate和可用域AZ。如果实例原本属于某个 AZ而目标节点不在这个 AZ 里迁移会因为调度过滤直接失败。实例组server group的亲和性策略也会影响调度比如 anti-affinity 策略要求同一组实例必须分布在不同的宿主机上你强行往同一台节点迁就会报错。3.2 存储、网络和 nova.conf 里的隐形前提存储面要检查三件事路径、权限、挂载。共享存储场景下源节点和目标节点的实例目录必须指向同一份数据。默认路径一般是/var/lib/nova/instances。我用 NFS 做共享存储时系统上线第一件事就是确认所有计算节点挂载路径一致、权限一致。排查命令如下mount | grep instances ls -ld /var/lib/nova/instances ls -Z /var/lib/nova/instances # 有 SELinux 时额外看下安全上下文本地盘场景下确认磁盘复制路径可达、目标节点磁盘剩余空间足够。网络面是另一个隐形炸弹。迁移后的实例通常 IP 不变因为网络配置跟随租户网络走但这要求目标节点能和源节点在二层网络互通并且网络节点能正常处理迁移带来的端口切换。如果用的是 VLAN 网络确保目标节点所属的 VLAN 能通如果用的是 VXLAN/OVS检查隧道端点之间 UDP 4789 端口是否放通。nova.conf 里影响迁移的关键参数我也列一下这些配置在控制节点的/etc/nova/nova.conf中[DEFAULT] # 热迁移超时时间默认1800秒超过则迁移失败 live_migration_timeout 1800 # 允许自动收敛内存不收敛时自动降速 live_migration_permit_auto_converge True # 允许后拷贝慎用 live_migration_permit_post_copy False # 停机时间上限毫秒 live_migration_downtime 500live_migration_permit_auto_converge我建议在生产环境直接打开。它对高写入负载的实例非常友好能避免迁移无限卡死。post_copy保持关闭除非你明确了解它在网络故障时的风险。3.3 迁移窗口与业务确认别急着敲命令。迁移是变更操作必须有窗口意识。我的习惯是冷迁移安排在业务低峰期且提前通知业务方明确大约有多长的停机时间热迁移虽然号称不中断但我也要求业务方在窗口期配合至少保证迁移期间不做大版本发布或压测迁移前对实例做一次快照Ceph 后端尤其方便万一迁移失败或者数据有问题还有回退的底牌。这一条看着像流程废话但在实际生产里我发现大多数迁移事故不是技术问题而是“业务方不知道你在动他的机器”。一个在迁移期间被误以为故障的投诉电话比任何技术故障都让人头大。4. 手把手操作冷迁移与热迁移全流程环境准备好之后实际操作并不复杂。这里以传统 nova 命令为主毕竟这套 CLI 在历史部署中非常普遍新版 openstack 命令我会标出来。4.1 定位实例、确认当前宿主机先找到要迁移的实例 ID 和所在节点openstack server list --all-projects nova show server-id | grep OS-EXT-SRV-ATTR:host记录下实例当前的宿主机迁移完成后需要对比确认。4.2 冷迁移完整动作与状态流转冷迁移命令nova migrate server-id # 如果实例磁盘在本地且没有共享存储需要加块迁移参数 nova migrate --block-migrate server-id新版 OpenStack 客户端写法openstack server migrate server-id --wait提交之后用 migration-list 跟踪迁移状态nova migration-list | grep server-id状态流转大致是queued → migrating → finished。实例本身的 OpenStack 状态会从 ACTIVE 变为 migrating迁完后回到 ACTIVE。这里有个细节如果实例原本是关机状态SHUTOFF冷迁移之后它依然是 SHUTOFF不会自动开机。别傻等它起来这不是迁移出问题了而是 Nova 尊重实例的原始电源状态。冷迁移成功后再确认一遍宿主机nova show server-id | grep OS-EXT-SRV-ATTR:host看到目标节点名冷迁移完成。4.3 热迁移命令与参数详解热迁移命令nova live-migrate server-id [目标主机名]不带目标主机名时Nova 会让 scheduler 自动挑选一个合适的节点。带目标主机名则是指定迁移但这个名字必须能被 Nova 识别且节点满足调度条件。本地盘场景加块迁移参数nova live-migrate server-id 目标主机名 --block-migrate新版 openstack 客户端的等价命令是openstack server live-migrate server-id --host 目标主机名参数逻辑基本一致。热迁移过程中的观察点有两个migration-list 里的状态以及实例本身是否一直保持 ACTIVE。如果迁移真的顺利你甚至看不到实例有任何状态变化。另外提醒一句热迁移期间千万不要对实例做冷迁移或者关机操作这会造成两个迁移操作互相打架轻则失败重则实例锁死需要人工解锁。4.4 Horizon 界面上的迁移入口不喜欢命令行的同事在 Horizon 面板上也能操作。进入“项目 → 计算 → 实例”页面选择目标实例展开下拉菜单能看到“迁移”或“更改主机”点进去后填目标主机留空则自动选择确认即可。Horizon 的底层调用的 API 和命令行完全一致本质没有区别。但批量操作时我还是建议用命令行或脚本因为 Horizon 易用性换来的是操作效率低下几十台实例一个个点按钮手会废。5. 迁移排错实战我踩过的几个坑迁移这个动作平时看着岁月静好一出问题就是生产事故。下面几个坑是我在实际环境里真刀真枪踩过的写出来帮你省点时间。5.1 NoValidHost不是主机不够是 filter 把它筛掉了现象执行nova migrate后API 直接报错nova-scheduler 日志里出现NoValidHost。我见过最多的情况其实不是资源不足而是 scheduler 的过滤条件把目标节点筛掉了。排查路径按顺序走确认目标节点服务正常openstack compute service list确认可用域/聚合组匹配openstack aggregate list看节点归属实例所在的 AZ 必须与目标节点一致确认实例组约束openstack server group list看亲和性策略确认资源余量openstack host show 目标节点重点看内存最后翻日志grep NoValidHost /var/log/nova/nova-scheduler.log日志里会写明具体是哪个过滤项把节点干掉的。这一套下来90% 的 NoValidHost 都能定位。别上来就怪资源不够先看调度器日志它把拒绝理由写得非常清楚。5.2 热迁移卡在 migrating内存不收敛和带宽瓶颈现象migration-list 状态永远是 migrating跑了几个小时还在飞。这种“卡死”最常见的原因是内存不收敛。实例是数据库、大数据计算这类高写入负载脏页生成速度始终高于拷贝速度迁移永远追不上。另外一个原因是磁盘块迁移时目标节点磁盘写入太慢整个迁移时间被拉长。处理办法第一选择开启live_migration_permit_auto_converge True。开启后 Nova 会强制降低虚拟机 CPU 频率让脏页速度降下来多数情况下能救回来第二选择检查迁移网络带宽是否被限速。nova.conf 里有live_migration_bandwidth参数默认不限速。但如果有外部限速策略比如 QoS迁移流量会被卡住需要调整网络侧的限速策略第三选择实在不收敛取消这次迁移让业务侧配合把负载降下来再试。我还遇到过一次热迁移卡住是因为目标节点的磁盘空间不够块迁移写到一半写不进去了。磁盘告警如果没接监控这种问题根本发现不了。所以迁移前我强烈建议先df -h确认目标节点磁盘余量。5.3 CPU 型号不匹配跨代际迁移的经典失败现象热迁移开始后不久直接失败nova-compute 日志里出现类似host CPU does not provide required features的报错。原因很简单源宿主机和目标宿主机的 CPU 特性集不一致。比如一个是 Intel Xeon E5 v2Ivy Bridge另一个是 Intel Xeon ScalableSkylake后者的某些 CPU 特性前者没有libvirt 在检查迁移兼容性时直接把请求拒绝了。解决思路有两个把[libvirt] cpu_mode从host-passthrough改成host-model。host-passthrough 把宿主机 CPU 完整透传给虚拟机性能好但对迁移极不友好host-model 会由 libvirt 计算一个各节点都能接受的通用 CPU 模型牺牲一点性能换迁移兼容性。如果非要跨 Intel/AMD 做热迁移现实点说别试了。即便某些配置能让 QEMU 跑起来很多指令集差异会在运行期引发不可预知的问题性能和稳定性都得不到保证。我这边的原则是热迁移集群内物理机型号尽量一致不一致就把 cpu_mode 统一改为 host-model并且提前做一轮迁移演练验证。5.4 共享存储路径不对迁移后实例起不来现象冷迁移显示 finished但实例在目标节点上起不来console 里只有 boot 失败或者 nova-compute 日志报“找不到磁盘文件”。这种问题 90% 出在共享存储的挂载一致性上。常见情况是新加入的计算节点没有正确挂载 NFS/Ceph或者挂载了但实例目录权限不对。实例的磁盘镜像在共享存储里但目标节点的/var/lib/nova/instances下面根本看不到对应文件Nova 自然无法启动实例。典型排查mount | grep instances ls -ld /var/lib/nova/instances还有一个隐蔽的坑NFS 挂载时如果加了root_squashnova 用户通常也是 root 权限服务写入会被 squash 成 nobody导致无法创建实例目录。这种问题日志里通常报 permission denied但很多人第一反应是查网络、查安全组绕一大圈才回来。所以我给所有存储运维同事的建议是迁移演练时不要只看“迁成功没”一定要做一次“迁完后实例能不能起来”的完整验证。5.5 失败之后如何收场回滚与重试的判断迁移失败不是世界末日但处理方式决定你是五分钟解决问题还是折腾两小时。冷迁移失败时Nova 一般会把实例留在源节点上但它已经被关机了一把业务已经中断过。这时候不要立即盲目重试。先确认源节点还稳定能做的话先把实例启动起来恢复业务然后排查失败原因再决定下一步。热迁移失败的表现更复杂。多数情况实例会留在源节点继续运行但也有少部分情况目标节点已经建立了部分实例数据。重试前一定要清理目标节点上的残留目录否则下一次迁移可能会因为目录已存在而失败。我个人经验是同一台实例热迁移连续失败两次就先停下来查日志而不是继续把按钮按到烂。很多热迁移问题背后是存储或网络层面的系统性故障重试解决不了根因。6. 迁移后的验证与更高阶的运维打法迁移完成不等于事情结束。真正负责任的运维至少要把“迁走了”和“迁好了”分开来对待。6.1 迁移后的六项确认我每次迁移后会按固定清单过一遍状态确认nova show server-id | grep OS-EXT-SRV-ATTR:host确认宿主机已变更实例状态为 ACTIVE网络连通从外部 ping 实例的浮动 IP确认网络面正常登录验证SSH 或远程桌面方式登进系统确认密钥/密码认证没问题业务探活访问业务端口或调一次健康检查接口数据完整性数据库类实例查一下表空间、文件系统挂载确认数据盘没丢控制台观察openstack console log show server-id看一眼启动日志排除内核 panic、磁盘挂载错误等隐患。热迁移的验证有一点特殊IP 和服务都不变的情况下很多人只看一眼 API 状态就宣告完成。但热迁移底层的 CPU 型号、内存一致性是否真的没问题必须通过实例内部检查来确认。我见过热迁移后实例内核报 CPU soft lockup 的情况就是因为目标节点 CPU 特性集差异导致这种只有登录实例看 dmesg 才知道。6.2 节点宕机后的整体疏散host-evacuate 的适用场景前面讲过节点彻底挂掉时应该走 evacuate而不是 migrate。把整个故障节点上的实例全部疏散到健康节点的命令是nova host-evacuate 故障节点主机名 --target 目标节点主机名这个命令会遍历故障节点上的所有实例并逐个在目标节点上重建启动。但注意host-evacuate有几个前提实例必须基于共享存储。本地盘实例的磁盘数据在故障节点本地节点挂了数据就没了evacuate 也没办法实例的“内存状态”会丢业务需要重启中断时间是必然的evacuate 是对运维判断的“最后手段”不要在节点其实还能抢救的时候用它。如果节点只是假死网络不通但进程还活着先试网络和 SSH 恢复不行再看 Nova 服务是否还能响应。确认无望了再 evacuate。顺序反了本来能优雅迁移的实例会变成强制重建业务影响被无谓放大。6.3 把迁移纳入自动化运维流程迁移操作如果只是在算费平台上手动点几百台实例会把你点崩溃。我日常是把迁移做成一个半自动脚本流程先生成一个实例清单确认哪些实例要迁移、目标节点是谁执行冷/热迁移命令轮询 migration-list等所有迁移状态变为 finished自动触发验证动作把迁移前后的宿主机信息输出到一个报告里。一个简单的轮询思路如下while true; do status$(nova migration-list | grep server-id | awk {print $8}) if [ $status finished ]; then break fi sleep 10 done更完整的生产环境做法我会把预检、迁移、验证拆成三个阶段用 Ansible 编排。预检阶段跑资源检查和挂载检查迁移阶段按窗口逐台执行验证阶段自动收集实例状态和网络连通性结果。整个流程跑下来手工操作时间能从两小时压缩到十分钟。有个细节要提醒批量迁移时一定要控制并发数。尤其是热迁移并发太高会直接把管理网络或存储网络打满反而拖慢整体进度。我的经验是共享存储场景并发不超过 5本地盘块迁移场景并发不超过 2稳妥第一。最后讲一个我自己的习惯。每次做批量迁移前我都会先挑一台最小实例做全流程演练确认共享存储、网络、权限这些基础面没问题之后再排批量。这看起来耽误十分钟实际上能省掉凌晨处理事故的两小时。尤其是热迁移界面上只是一个按钮底层是 libvirt 里一场数百 GB 内存页的接力赛任何一环出问题都会让业务中断。宁可慢不要浪是我做迁移这几年最大的心得。