1. 为什么说 Nova 的操作比你想的多得多做过 OpenStack 运维的人都有这种体会Nova 表面上是“管虚拟机”的组件但真正上手之后才发现它那套操作体系的复杂度远超预期。单说对一个 instance 的管理官方 API 文档里列出的动作就有二十几项而我们在实际生产环境里真正会用到、必须掌握的我数了一下核心就有 16 种。这 16 种操作既有像create、delete这种一眼就能看懂的基础动作也有evacuate、rescue、shelve这种平时不碰、但故障时能救命的高级功能。问题在于很多刚入门的运维同学根本不知道 Nova 还提供这些能力等真到机房断电、宿主机宕机、镜像启动失败的时候才一头扎进文档里现查一边查一边心跳加速。我写这篇东西就是想把这 16 种操作按“生命周期管理”“状态迁移”“故障处理”“资源调整”四条线捋清楚每一条线配图说话。读完你会发现Nova 其实有一套很完整的思想在背后支撑一切操作都是状态的迁移一切状态迁移都遵循统一的生命周期模型。看懂了这条主线16 种操作不用死记你自己都能推导出个大概。这个系列前面的文章一直在讲 Nova 的架构、组件、调度逻辑这篇我们换个角度拿操作当入口把 Nova 的行为模型完整地过一遍。适合正在学 OpenStack 的读者也适合已经在做云平台运维、想系统梳理 Nova API 能力的老手。2. Nova 操作背后那套统一的状态机模型在拆解具体操作之前必须先理解 Nova 内部那张“状态流转图”。可以说16 种操作只是这张图上的路径按钮按下去虚拟机就在不同的状态之间跳转。2.1 核心状态有哪些Nova 对一台虚拟机的生命周期管理用两个维度的状态来描述一个是power_state代表虚拟机在 hypervisor 层面的真实运行状态比如运行中、已关机、挂起另一个是vm_state代表 Nova 自己认为虚拟机处于什么阶段比如 ACTIVE、BUILD、ERROR、SHELVED_OFFLOADED 等。这两套状态经常让新手困惑。举个例子你执行nova stop之后虚拟机的 power_state 变成了 SHUTDOWN但 vm_state 仍然可能是 ACTIVE。为什么因为 ACTIVE 在 Nova 的定义里并不是“正在运行”而是“这个虚拟机实例是活的、可以被正常操作的”。它只是被关机了但 Nova 认为它还是一个正常可用的实例。同理nova pause和nova suspend的区别也只有在理解了状态模型之后才能讲得清楚。看状态是运维的第一步。遇到任何虚拟机异常先别猜用openstack server show uuid看字段power_state 和 vm_state 一对照问题往往就定位了一半。2.2 状态迁移是怎么触发的Nova 的操作最终都会落到 conductor 和 compute 两个服务的配合上。用户通过 API 发起请求API 层把请求转给 conductorconductor 通过消息队列告诉对应节点上的 nova-compute 执行具体动作。动作执行的过程中compute 服务会不断地通过版本化通知把状态变化汇报给数据库于是你会看到 instance 的状态在 API 查询结果里一步步变化。这个设计有几个实在的好处一是 API 层可以快速返回不会因为底层操作慢而让调用方干等二是因为状态都落在数据库里控制节点挂了对实例的追踪结果也不会丢三是状态机的每个转换点都可以插入校验逻辑防止用户发出前后矛盾的指令比如对一台正在删除的机器执行迁移操作。2.3 为什么理解状态机这么重要我见过不少人把 OpenStack 玩成“命令背诵大赛”nova list、nova reboot背得滚瓜烂熟但一遇到异常就抓瞎。原因就是只记住了命令的“按下去会有反应”没记住“按下去之后系统内部发生了什么变化”。状态机模型的价值在于它把所有操作还原成了“从一个状态走到另一个状态”的合法路径。你会明白为什么nova resize之后实例会进入 VERIFY_RESIZE 状态、为什么这时候需要 confirm 或 revert会明白为什么nova shelve之后实例不再占用计算节点的内存资源但卷和镜像还被保留着。带着状态机的视角去学操作你会发现它们之间是有逻辑关联的而不是 16 条孤立的命令。3. 生命周期管理类操作从创建到删除的完整闭环这一组是 Nova 最基础、也最常用的操作覆盖了一台虚拟机从“出生”到“销毁”的全过程。3.1 create一台虚拟机是怎么诞生的创建虚拟机的完整过程我在前面的文章里详述过这里只提炼和操作相关的要点。nova boot或openstack server create并不是一条命令发出去就万事大吉了它背后涉及 flavor 匹配、镜像选择、网络规划、块设备映射每一步都有默认参数但每一项在生产环境中几乎都需要根据实际需求调整。实操中最大的坑是很多新手不校验配额。nova quota-show先看一下项目还剩多少 vCPU、内存、磁盘和浮动 IP否则 create 命令发出去了实例直接进入 ERROR 状态排查起来费时费力。创建命令里几个值得关注的参数--availability-zone指定可用域生产环境建议必须显式指定避免调度器随机散落导致管理混乱。--key-name指定 SSH 密钥如果不上传密钥密码获取也会变成一件麻烦事。--block-device-mapping这个参数要重点练习它决定了根盘是镜像启动还是卷启动生产环境基本都要求 boot from volume因为本地盘在宿主机故障时数据没法跟着走。--config-drive开启后配置信息会写入虚拟机可见的配置盘中云初始化场景下很有用。创建是很典型的“发起后轮询”操作。集群规模一大create 请求发出到实例 ACTIVE 可能要等几分钟期间一定要学会用openstack server show去观察状态流转而不是傻等输出。3.2 delete没有回收机制的生产环境是会爆的删除操作有几种不同的力度nova delete是常规删除把实例从计算节点上清理掉但关联的卷默认是不删的nova force-delete是强行删除当实例状态异常、正常删除流程卡住的时候用如果卷也要一并清理需要单独处理卷的删除。有个经验删除之前先看清楚这台机器有没有挂载独立数据卷。经常有运维手一抖把虚拟机删了才发现数据库数据还在卷上虽然卷保住了没删但恢复的流程会绕很大的圈子。生产环境的常规做法是给删除操作加一道审批至少是双人复核。另外一个容易被忽视的点是删除实例时其占用的浮动 IP 会被释放回池中。如果你只有一个浮点 IP 池瞬间可能被耗尽。所以删除之前检查一下 IP 池水位这也是运维习惯的一部分。3.3 rebuild快速恢复被玩坏的虚拟机nova rebuild是很多人忽略的一个好功能。它能把一台虚拟机恢复到指定镜像的初始状态常用于系统文件损坏、配置改崩了的场景。关键的是它在执行时会保留实例的 ID、网络配置和浮动 IP不会造成“换新机器要重新绑 IP”的麻烦。这个操作有一个重要特性默认情况下它是不保留原实例数据的等于把系统盘清空重来。如果机器里存了重要文件rebuild 前一定要先把数据拷出来。命令参数里--preserve-ephemeral可以保留临时盘但系统盘数据仍然会被重置。rebuild 和 delete create 的区别就在于它能保持实例 ID 不变。对依赖主机标识hostname、实例 ID做授权的系统来说rebuild 是唯一靠谱的“重装系统”方式。3.4 start、stop、restart电源管理的三兄弟这三个动作对应着虚拟机的真实电源控制。start 让 SHUTDOWN 状态的实例开机stop 让 ACTIVE 的实例关机restart即 reboot是重启。单独看都很简单但结合起来就有很多经验之谈。nova reboot在 Nova 中分为软重启和硬重启两种。软重启是在客户机操作系统内发起重启流程适合正常业务场景硬重启等于直接断电再加电适合操作系统卡死、发软重启没反应的场景。命令上可以通过--hard参数控制默认走软重启。停机的坑主要在依赖关系上如果你的业务是多台虚拟机配合工作的先停谁后停谁是有讲究的Nova 本身不感知业务依赖停了一台依赖服务另一台可能瞬间报错。所以停机前梳理业务拓扑是老运维的习惯动作。4. 状态迁移类操作暂停、挂起、快照、锁定这组操作的共同点是不会终结虚拟机而是让它以某种形式“冻结”或“暂离”适合需要长时间保留但暂时不用的场景。4.1 pause 和 suspend看起来差不多本质完全不同这两个操作日常经常被混为一谈但原理差异很大。nova pause把虚拟机的运行状态保存在宿主机内存里对 hypervisor 来说就是执行一个暂停指令。优点是恢复快因为内存内容还在缺点是一旦宿主机重启暂停状态就没了实例可能会变成 ERROR。nova suspend则会把内存状态写到磁盘上可以跨宿主机重启保留恢复比 pause 慢一些但更持久。我遇到过一例有同事给一台 Windows 机器执行了 pause后来宿主机做内核升级重启重启完发现虚拟机状态直接 ERROR 了业务中断半天。这就是没有理解 pause 的非持久性导致的事故。生产环境如果要做超过几十分钟的暂停优先选择 suspend 或者 shelve。4.2 snapshot备份的基础也是误解的重灾区很多人以为快照就是“给虚拟机拍个照片”随手一点就完成。其实 Nova 的 snapshot 分两种一种是把运行中的实例打包成镜像另一种是底层存储如 Ceph对卷打快照。这两种东西虽然都叫快照但用途完全不同。nova image-create是把实例当前状态打包成一个 glance 镜像可以用来创建新实例。打包出来的系统盘反映的是打快照那一刻的状态不是“数据完全一致”的那种备份特别是对数据库这类常驻写盘的应用建议先冻结文件系统再做快照。它不包含内存状态也就是说你创建出来的新实例启动后是一个“干净开机”的机器而不是原机的完全克隆。如果用的是 Ceph 后端存储更靠谱的备份方式是直接在 Ceph 层面对卷做快照。但要注意Ceph 的块设备快照本身不是自动的需要手动协调。生产环境建议用专门的备份工具比如开源的 openstack-backup 脚本不要裸写命令。4.3 lock 和 unlock防止误操作的最后防线nova lock其实是一个管理锁锁住的实例不能执行任何变更类操作包括 reboot、resize、delete、snapshot 等。它是防止手滑的好工具尤其是对数据库和核心业务机建议上线以后就默认锁上。有个细节lock 只约束 API 层的变更请求底层 hypervisor 的异常重启不在它的管辖范围内。所以 lock 不是高可用机制只是操作审批机制。另外lock 之后如果需要紧急 reboot必须先 unlock这个解锁动作在堡垒机上是要有审计记录的。5. 资源调整类操作扩容缩容的完整姿势5.1 resize改规格的正确方式Nova 中改实例规格是nova resize它的本质是在同一宿主机或另一台宿主机上用新的 flavor 重建一个实例然后让你确认结果。执行后实例会进入 VERIFY_RESIZE 状态登录上去看 CPU 内存是否符合预期确认没问题就执行nova resize-confirm不想换就nova resize-revert退回去。这套流程最主要的坑在于resize的生效范围取决于底层的磁盘类型。如果实例用的是 ephemeral 本地盘resize 一般都能成功如果用的是 LVM 或 Ceph 卷后端因为卷在创建时已经固定了大小仅仅改 flavor 可能并不会真正扩容根盘。很多运维跑完 resize 发现磁盘还是原来的大小就是这个原因。要扩容根盘得走卷扩展的流程然后进实例里用工具扩展分区。生产环境下 resize 是变更操作里风险最高的之一特别是缩容把 8C16G 降到 4C8G可能会导致客户机内应用因为内存不足直接 OOM。建议缩容前和业务方确认实际用量别只想当然看 flavor 参数。5.2 evacuate宿主机挂了虚拟机怎么抢救evacuate 是 Nova 的灾备机制当一台宿主机宕机或网络不可达上面跑的虚拟机全部变成 ERROR 状态时可以执行nova evacuate把实例迁移到其他健康节点上。要注意的是evacuate 能不能保住数据取决于你用的是本地盘还是共享存储。如果实例是用本地盘跑的evacuate 能救回来的只有“操作系统配置”这个壳数据盘的数据大概率拿不回来。所以生产环境必须把数据卷放在 Ceph 或者其它共享存储上evacuate 才有真正的实际意义。执行前建议先确认目标可用域内有资源并且检查一下实例是否绑定了别的依赖服务比如浮动 IP、安全组。我见过有人 evacuate 完发现浮动 IP 没绑定业务照样不通最后排查半天才反应过来。evacuate 本身不负责把网络配置也原样恢复有些环节要手动补。5.3 shelve 和 unshelve长时离线的最优解shelve和suspend类似但它比 suspend 更进一步shelve 之后实例会从计算节点上完全卸载内存、CPU 资源全部释放只剩下卷和镜像元数据保留在云平台上。unshelve则把这些状态重新装载回计算节点。这个设计对资源利用率是大有可为的一台一年只用一次的测试机长期 ACTIVE 白占着 CPU 和内存给它 shelve 掉资源立刻释放等要再跑的时候 unshelve 起来即可。代价是 unshelve 的启动时间明显比 suspend 恢复慢毕竟等于重新“冷启动”一台机器。shelve 的一个小坑它默认也会对系统盘做一次快照作为状态保存所以每 shelve 一次都会占用一点镜像存储空间。不用惊讶 Ceph 池为什么会有多余的那些镜像八成是之前 shelve 操作留下的。6. 故障处理类操作救命技能全梳理6.1 rescue 和 unrescue系统盘崩了也能临时救命rescue 是一个很有价值的“急诊功能”它用一个新的镜像通常是救援镜像启动一个临时实例同时把原来实例的系统盘挂载到这个临时实例上。这样运维人员可以登录到临时实例里挂载原系统盘进行修复——改配置、清空异常文件、升级内核都可以。执行nova rescue之后原实例进入 RESCUE 状态原来的 IP 配置会暂停临时实例会拿到一个救援用的 IP。修复完成再执行nova unrescue就会恢复原来的系统盘启动实例回到原状态。实操中最容易忽略的是救援实例要能访问到原实例的内网安全组需要放通相应端口否则登录进去也连不上原盘。很多救援失败不是命令错了是安全组挡了路。6.2 backup按策略做周期备份虽然 Nova 提供了nova backup命令用于做周期性备份但说实话现在生产环境更推荐在 Ceph 层直接做卷快照或用第三方的备份方案。Nova 自带的 backup 每次都会生成一个完整的镜像备份频率高了存储开销非常大而且恢复路径也比较绕。如果一定要用记得设置合理的保留策略定期清理老旧备份镜像。否则你会发现镜像服务里堆了一大堆备份产物占空间不说镜像列表查起来也费劲。6.3 live migrate无感知迁移的实战细节在线迁移live migration是运维高阶技能里绕不开的一环。宿主机要做内核升级、要更换硬件、要均衡负载都需要把正在运行的虚拟机平滑迁移到别的节点上全程业务不中断。前提条件非常核心目标宿主机的 CPU 必须和源宿主机兼容最好同型号同架构跨型号在线迁移大概率失败并且实例的磁盘必须在共享存储上。命令是nova live-migration server也可以指定目标主机不指定时由调度器自动选择。迁移过程中必须盯紧网络OpenStack 的 QoS 策略、安全组规则在迁移后要保持一致否则流量会莫名其妙不通。另外大内存的虚拟机进行 live migration 时耗时长期间如果网络抖动迁移可能停下来甚至回滚运维要设置合理的超时预期。6.4 12 个冷操作与 4 个热操作的心智模型如果把 Nova 的 16 种操作按“热”“冷”来分一下会让记忆负担减轻不少。4 个热操作是 create、delete、start、stop日常最常用、命令最基础。12 个冷操作是 rebuild、resize、snapshot、rescue、pause、suspend、shelve、evacuate、live migrate、lock、unlock、force-delete单独拎出来每一个都是在特定场景下才激活的能力。冷操作最大的风险是不常碰、容易生疏。所以建议运维团队定期做故障演练把冷操作轮着执行一遍确保关键时刻手不抖。只背命令不清流程一到真故障时容易在选项上反复犹豫错过最佳恢复窗口。7. 一张图串联 16 种操作的速查框架这一节直接给速查框架但鉴于平台限制没办法画一个真正的图片所以用文字表格的方式把它描述出来。照着这个思路你可以自己画一张图用状态节点连线来记忆。操作影响状态是否中断业务典型场景关键参数createBUILD → ACTIVE新建部署新业务flavor/镜像/网络deleteACTIVE → DELETED是下线业务force-delete 兜底rebuildACTIVE → REBUILD → ACTIVE是系统崩溃重装preserve-ephemeralstartSHUTDOWN → ACTIVE否启用已关机实例-stopACTIVE → SHUTDOWN是关机维护-rebootACTIVE → ACTIVE短暂中断系统重启hard/softpauseACTIVE → PAUSED是短时暂停CPU/内存保留suspendACTIVE → SUSPENDED是长时暂停内存落到磁盘shelveACTIVE → SHELVED_OFFLOADED是释放资源长时离线快照占用存储unshelveSHELVED → ACTIVE否恢复离线实例冷启动时间resizeACTIVE → VERIFY_RESIZE是变更规格confirm/revertsnapshotACTIVE → 保持不变否有 IO 影响做成镜像需冻结文件系统rescueACTIVE → RESCUE是系统盘修复安全组放通lockACTIVE锁状态否防误操作unlock 才能变更evacuateERROR → ACTIVE是宿主机宕机依赖共享存储live migrateACTIVE → ACTIVE否平滑搬迁CPU 兼容把这张表装进脑子里遇到实际问题时定位就快多了。我自己习惯是遇到故障先问三个问题这台机器现在什么状态我想让它变成什么状态从当前状态到目标状态有哪些合法路径问完这三个问题操作基本就浮出水面了。8. 排障实录状态卡住之后的排查套路实操中最容易出的问题就是状态卡在中间比如 BUILD 了半天不动、REBOOT 卡死、RESIZE 后一直停在 VERIFY_RESIZE。这类问题的排查思路其实高度统一先看 compute 节点的日志再看消息队列最后看数据库状态。我整理几个高频的案例。8.1 BUILD 状态不动的排查创建虚拟机卡在 BUILD 状态优先级最高的怀疑对象是资源不足和调度失败。登录控制节点执行openstack compute service list看 nova-compute 服务是否都正常再看nova-conductor日志里有没有调度相关的报错。如果日志里提示 no valid host那就是 flavor 要求的资源在目标节点上不够或者可用域配置有问题调整 flavor 或增加节点资源即可。接着看计算节点上的nova-compute.log里面对应实例 UUID 的日志片段会明确告诉你卡在哪个环节比如是网络创建等待超时、还是卷挂载失败。网络创建超时在 Neutron 组件故障时非常常见那时候光看 Nova 日志是不够的要跨组件排查。8.2 REBOOT 卡死的处理实例明明执行了 reboot但状态一直没回到 ACTIVE可以先确认是不是进入了硬重启流程。硬重启对某些虚拟机来说需要预留足够的启动时间特别是 Windows 虚拟机启动本来就慢超时设置太短就会显示重启失败。这时候看 compute 日志确认 libvirt 层面的操作成功没有。libvirt 命令执行成功但 Nova 状态没更新多半是消息队列有积压导致状态通知没送达看看 RabbitMQ 的队列积压情况通常清掉积压任务后状态就回恢复正常。8.3 状态不一致的兜底思路最后提一个经验如果数据库里 instance 状态和真实虚拟机状态不一致最直接的兜底手段是nova reset-state。它能手动把状态强制重置为 ACTIVE 或 ERROR但它只改数据库记录不会动真实虚拟机的任何东西。所以用之前务必确认底层真实状态否则会把假状态当真问题引发二次误操作。更稳妥的做法如果状态差异无法靠日志定位可以把这个实例做一次在线的配置对比——检查 libvirt 里该 UUID 对应的 domain 是否存在检查卷挂载列表和数据库记录能否对应上。没有对应的按孤儿资源清理有对应的尝试用 force-delete 或重置状态来恢复管理口径。9. 我踩过的几个坑希望你别再踩最后分享几个比较难发现的细节问题都是实际运维过程中踩出来的。第一个是flavor 的 ephemeral 盘和 resize 的关系。有次为测试机扩容从 20G 临时盘扩到 40Gresize 完登录看到 /dev/vdb 还是 20G。原因是 Nova 的 resize 操作对临时盘的重建只在新节点上生效旧节点上的临时盘数据如果在共享存储里并不会自动扩容。后来是通过迁移到新节点重建实例才解决的。所以 resize 只适合相同的磁盘后端拓扑改动临时盘大小要提前确认底层存储的响应。第二个是suspend 状态对 OpenStack 版本升级的影响。某次平台升级升级脚本直接遍历实例做冷迁移结果 suspend 状态下的实例无法进行冷迁移升级流程卡了大半天。后来先把所有 suspend 的实例 unsuspend 或者直接标记跳过才顺利继续。第三个是live migrate 对 CPU 特性要求的低估。跨型号迁移比如从 Intel Xeon 迁移到 AMD EPYC即使 CPU 模式配了兼容模式仍然可能碰到 AVX 指令集差异导致虚拟机运行异常。在线迁移前最好先在测试环境跑一遍同款迁移验证业务稳定再批量操作。第四个是镜像快照对数据库类应用的影响。拍快照时如果不预先冻结文件系统特别是 MySQL、PostgreSQL 这类恢复出来的空间数据可能是损坏的。负责的运维在做数据库备份快照前都会先协调业务方做一次 flush tables with read lock或者干脆用专业备份工具。10. 后续还可以怎么玩把 Nova 操作接入自动化编排讲了这么多命令和操作要说这些内容在真实运维里最大的价值我认为不是帮你多敲几条命令而是帮你形成“操作编排”的思维。现在主流的运维平台都开始用 Ansible 或者自研的运维中台来封装 OpenStack 操作这时候知道 Nova 有哪些操作、每个操作的状态变化、哪些操作之间有关联关系就特别关键。举个例子一个自动化的宿主机维修流程可以做这么一系列的动作先把该节点上所有虚拟机 live migrate 走 → 再检查是否还有残留实例 → 把节点置为维护状态nova service-disable→ 维修完成后重新 enable 节点 → 把之前迁走的实例迁移回来。这一套流程里的每一步本质都是 Nova 操作的有序编排。懂 Nova 操作的人能高效设计这个流程而只懂命令的人只能一步步人工执行既慢又容易出错。另外Nova 的操作现在也大量暴露在 Horizon、OpenStack SDK 和 Terraform Provider 中。如果你用 Python 写自动化脚本直接调用openstacksdk的compute接口可以实现同样一套生命周期管理。现在的多云编排平台也大多兼容 OpenStack API就是说你学会了这 16 种操作以后迁到其他云平台很多概念依然通用——虚拟机生命周期模型是云计算领域的通用语言。这套思路在整个 OpenStack 系列里也只是一个起点。Nova 操作深入了Cinder 的卷操作、Neutron 的网络操作、Heat 的编排操作都有类似的状态机和动作模型。学完 Nova 再去看别的组件你会发现脚手架已经搭好了剩下的只是换参数、换资源类型而已。