上周五傍晚业务群里有人喊了一句“那台跑内部报表的云主机今天不用了直接删掉吧。”我下意识追问了一句“数据确认过吗卷要不要留”对方有点不耐烦“删个机器而已还能有多复杂”后来我在工单里备注了 OpenStack 里 Terminate Instance 和普通关机的差别又顺手把 Pause/Resume Instance 这对操作一起复盘了一遍因为很多用户嘴上说要“删除”实际要的只是“先别跑但别动我的数据”。这篇就把 Nova 里这两个操作完整拆一遍适合正在维护 OpenStack 或者虚拟化平台、以及刚接手 Nova 计算服务的朋友。我会讲清楚 Terminate 和 Pause/Resume 的底层状态机变化、CLI 与 Horizon 两条操作路径、生产环境里我实际踩过的坑和排错步骤最后给出不同场景下该怎么选操作的经验判断。1. 先对齐认知Terminate Instance 是“拔电拆机”不是“关机锁门”1.1 Nova 里没有软删除Terminate 就是终局很多人第一次接触 OpenStack 时会把 Terminate Instance 理解成“把机器关掉”。这个误解非常危险。在 Nova 的语义里Terminate 对应的是删除实例不是停止实例。API 层面就是DELETE /v2.1/{project_id}/servers/{server_id}CLI 里对应的常见命令是openstack server delete或老的nova delete。这个操作一旦执行实例在整个 OpenStack 里的生命周期就结束了数据库里的 instance 记录会被标记删除配置的磁盘、网络端口、浮动 IP 也会按策略释放或回收。拿生活中的例子类比关机停止Stop等于把房间门锁上里面的家具、装修都还在下次开门还能继续用而 Terminate 等于把整间房拆掉砖块、门窗、水电管线全部按约定回收想再要这间房只能重新建。这里没有“后悔药”除非你在删除前做了快照或备份。所以我一直跟团队强调Terminate 是 OpenStack 运维里少有的“不可逆操作”之一任何自动化脚本在调用删除逻辑之前都必须过一遍数据确认。还有一个容易混淆的点是nova force-delete。常规删除遇到实例处于 ERROR 状态或卡在奇怪状态时普通 delete 可能不被接受这时候nova force-delete可以强制发起删除流程。它同样是删除只是更“粗暴”用来处理状态异常的实例。老版本 Nova 还有软删除soft delete的概念但主流版本早就不再暴露给用户默认行为就是硬删除。所以你在界面上看到的 “Terminate Instance” 按钮和 CLI 的 delete 是同一个动作不存在“界面上是软删、命令行是硬删”的区别。1.2 删除实例时底层同时在做三件事销毁计算、解绑卷、回收网络我在排查线上问题时发现很多人只关注“实例有没有从列表消失”却忽略了一条完整删除链路实际包含的三个方面。第一是计算节点的销毁动作。nova-compute 收到删除消息后会把 libvirt 里对应的 domain 销毁。对于 KVM 来说如果实例还在运行底层会先尝试发送 ACPI 关机信号取决于镜像的电源管理支持和实例的 shutdown 策略等待一个窗口期后如果客户机没有正常关停就直接调用virDomainDestroy强制销毁相当于拔掉电源。这一步会把 vCPU、内存、宿主机上的临时文件都清理掉。为什么生产环境建议先openstack server stop再删因为先把客户机系统内部的服务停干净避免删除瞬间数据丢失这个习惯能省掉不少“删完后说数据丢了”的争吵。第二是卷的处理。实例挂着的云硬盘不会自动消失。是否删除卷取决于创建实例时的delete_on_termination标记。如果这个标记为 true删除实例时引导卷会被一起删掉如果是 false卷会被解绑并留在卷列表里状态变成 available。很多运维事故就出在这里用户以为实例删了卷也没了结果 Cinder 里还躺着几十 GB 甚至上 TB 的卷费用和存储空间一直在消耗。我这里不是要说“卷该不该删”而是想说删实例之前先确认一下卷的归属策略别让“我以为会删”变成“我以为会留”。第三是网络资源的回收。实例删除后Neutron 会释放绑定到该实例的 port与之关联的浮动 IP 会从实例上解绑。固定 IP 会回到子网池浮动 IP 回到可用列表或者释放回外部网络。这里最常见的坑是port 没有正常清理会导致 IP 被“占住”新建实例时同一个 IP 分配不出去或者干脆冲突。所以验证一次删除操作是否成功不能只看 server 列表必须同时检查卷和网络资源。2. 完整的终止实例实操CLI 命令与 Horizon 按钮的真实清理流程2.1 推荐 CLI 路径先优雅关机再执行删除命令行是运维的主战场。我用的是 python-openstackclient也就是openstack命令相比老牌的nova命令更通用一套工具能管 Nova、Neutron、Cinder 等。下面是删除实例的推荐操作序列。# 1. 确认实例当前状态和挂载信息 openstack server show vm-01 -c id -c name -c status -c addresses -f yaml # 2. 如果实例还处于 ACTIVE先优雅关机 openstack server stop vm-01 # 3. 确认状态已经变成 SHUTOFF openstack server show vm-01 -c status -f value为什么先 stop 再 delete因为openstack server delete默认就是强制终止语义它不会等客户机内部完成优雅停机。对于跑数据库、消息队列这类看重一致性的业务直接在运行状态下delete客户机相当于被瞬时断电最后一批未落盘的事务可能会丢。先 stop 之后客户机操作系统会收到 ACPI 关机事件正常走完关机流程然后再执行删除整体更稳。等到状态确认是 SHUTOFF 之后就可以执行删除了# 4. 执行删除 openstack server delete vm-01 # 5. 查询确认这时候应该报 404 openstack server show vm-01有一点要提醒如果实例本身就在 ERROR 状态用openstack server delete不一定能成功可以先尝试nova force-delete server。老版本nova命令在部分部署中仍然有效。注意区分force-delete是强制让 nova-compute 去清理不代表会跳过底层资源清理逻辑它能帮你跨过状态机卡死的关卡但不会绕过卷和网络的处理。所以用了 force-delete 之后验证步骤要做得更仔细。2.2 删除后三查server、volume、network 一个都不能少删除完成不代表万事大吉我习惯做三查# 一查server 是否已经消失 openstack server list --all-projects | grep vm-01 # 二查卷是否还在状态是否变成 available openstack volume list | grep vm-01 openstack volume show 卷ID -c status -c attachments -c name # 三查端口和浮动 IP 是否已经解绑 openstack port list --device-id 实例UUID openstack floating ip list | grep 实例UUID卷的查询比较关键。如果你不确定这个卷是引导卷还是附加数据盘删除后卷还在是正常的如果你希望删实例时连引导卷一起删但创建时没勾选 delete_on_termination卷就会保留。我见过不少团队把“删除实例却不删卷”当作默认策略因为担心数据盘被误删这个思路没问题但必须定期巡查 Cinder 里的 orphan 卷否则存储成本会悄悄上升。网络层面的查询主要盯两个点openstack port list --device-id UUID应该返回空openstack floating ip list里不应该再有绑定到这个实例的记录。如果 port 没删干净第二个用同一个固定 IP 创建的虚机就会起不来如果浮动 IP 没回收外部用户访问该 IP 时会直接不通。这两个都是我实际遇到过的“删除后遗症”。2.3 Horizon 里的 Terminate 按钮界面操作与状态变化如果环境给业务团队开放了 Horizon 面板他们大概率会直接在实例列表右侧点击 “Terminate Instance” 按钮。这个按钮的位置在不同版本里略有差异有的在实例详情页有的在行操作菜单里但背后调用的 API 与 CLI 的 delete 完全相同。在 Horizon 上操作后实例状态会从 ACTIVE 先变成 DELETING或者瞬间直接消失取决于版本和响应速度然后从列表里消失。如果实例删除卡住列表里会长期残留一个 DELETING 状态的实例手动刷新也不会消失。此时不要反复在界面上点删除因为 API 层可能会拒绝重复请求正确做法是转到底层去定位也就是第 4 章要说的排查链路。我不太推荐生产环境用 Horizon 做批量删除。界面操作适合单台验证、测试环境清理批量场景还是写脚本走 CLI 更可控至少能在每台删除前加确认逻辑并把输出写到日志里。3. Pause/Resume 实战暂停在内存里的实例恢复可以按秒算3.1 Pause 的底层原理libvirt 的 virDomainPausePause/Resume 是一对容易和 Suspend/Resume 搞混的操作。Pause 在 Nova 里对应的是 hypervisor 层面的暂停nova-compute 调用 libvirt 的virDomainPause把客户机的虚拟 CPU 全部冻结。进程、内存、打开的连接、设备状态全部保留在宿主机内存里客户机内部并不会感知到关机或重启只会觉得时间突然“停了”等 Resume 时virDomainResume一调用虚拟 CPU 继续运行整个系统几乎是无缝恢复。这个特性决定了 Pause 的两个关键特点。第一恢复速度极快因为内存根本没有被持久化到磁盘不用像冷启动那样重新载入内存镜像秒级就能回来。第二它不释放内存资源。你以为暂停之后宿主机内存会空出来并不会内存占用还在。Pause 只是让 CPU 不再执行客户机指令但内存页不会还回去。这也意味着如果你想通过 Pause 来“腾资源”给其他虚机大概率要失望内存瓶颈的场景下该跑不动的还是跑不动。还有个容易忽略的点Pause 依赖宿主机的物理内存持续供电。如果宿主机重启PAUSED 状态的实例内存内容会全部丢失libvirt 里对应 domain 也没了。这时候 Nova 数据库里虽然还记着这个实例是 PAUSED但底层已经没有任何可恢复的东西了。后面第 4 章我会专门讲这个坑的后果。3.2 执行 Pause/Resume命令、界面、状态机命令行下操作很简单# 暂停实例 nova pause vm-01 # 查看状态会看到 PAUSED openstack server show vm-01 -c status -c task_state -c vm_state # 恢复实例 nova unpause vm-01 # 新版 client 里也有对应语法但兼容最稳的还是 nova pause/nova unpause也可以到计算节点上验证底层 domain 状态virsh list --all | grep 实例UUID virsh dominfo 实例UUID如果实例已暂停virsh dominfo的输出里 State 会显示paused。这一步是判断问题层级的好方法Nova 里显示 PAUSED 但 libvirt 里 domain 不存在说明上层状态和底层状态已经脱节接下来的处理要谨慎。Horizon 里实例的操作菜单中会有 “Pause Instance” 和 “Resume Instance” 选项。执行后实例状态会变成 “Paused”恢复操作在状态为 Paused 时才会出现。界面上看很简单但它的底层语义和 Suspend 完全不同不要被这两个英文单词的相似性带偏。3.3 Pause 与 Suspend、Shelve、Stop 的对比别用错方案这一段是很多人没仔细琢磨过的知识盲区。我整理了一张对比表把我运维视角下的关键差异列出来。操作底层行为内存资源CPU资源磁盘/卷网络端口恢复方式宿主机重启影响StopACPI 关机后销毁 domain释放释放保留保留冷启动无影响重新 start 即可PausevirDomainPause 冻结 VCPU驻留内存停止执行保留保留秒级恢复内存丢失实例异常Suspend内存写入宿主机磁盘释放释放保留保留取决于内存量和磁盘速度可以 resume 回来Shelve镜像上传 Glance 并清理计算资源释放释放镜像化保存保留端口慢无影响unshelve 即可Terminate销毁所有关联资源释放释放按 delete_on_termination 处理回收不可恢复无影响从表里能明显看出来Pause 最大的价值是“快”不管是暂停还是恢复都快。但它不是省资源的方案更不是长效方案。如果你需要宿主机进入维护窗口重启前必须把所有 PAUSED 实例处理掉要么先 unpause 再正常关机要么直接迁移到其他宿主机否则重启后这些实例很可能变成数据不连续的异常状态。Suspend 和 Pause 的区别可以类比成“闹钟暂停”和“笔记存档”。Pause 是大脑里的任务先冻结醒来还能接着想Suspend 是把想法写到笔记本上腾空大脑再去干别的。Shelve 则更进一步把整个“书房”都拍成照片存起来书桌可以给别人用要用的时候再按照片重新搭一遍。所以我在生产里一般这样用临时排查问题用 Pause计划内宿主机维护用 Suspend长期不用的测试机用 Shelve确认没用的业务机直接 Terminate。3.4 什么场景才算真正适合用 Pause这里分享一个我筛选过的判断标准满足其中两条以上我才建议用 Pause希望恢复时间在秒级冷启动完全不能接受。暂停时间预计在 30 分钟到 2 小时以内且不会跨越宿主机重启窗口。客户机内有长连接、实时缓存或者不便重启的服务暂停比关机更容易保持运行现场。宿主机内存充裕你不在乎暂停期间内存继续被占用。反过来说如果一台虚机要“暂停”一整天甚至更久不要用 Pause用 Suspend 更合适。如果是为了给同一台宿主机上的其他大虚机腾内存Pause 根本帮不上忙直接 Stop。我从实践中悟出来的经验是Pause 是一个“手术中的暂停键”不是“长期休眠开关”把它当成后者使用早晚会在宿主机维护或者内存压力事件里栽跟头。4. 线上踩坑复盘实例删不掉、恢复不了的定位链路4.1 实例卡在 DELETING第一步先看动态状态实例卡在 DELETING 是我收到过最多的求助类型。现象很统一Horizon 或者 CLI 里实例一直处于 DELETING刷新几小时都不消失。这时候最忌讳的就是反复点击删除按钮因为 Nova 的 API 层通常已经在等 nova-compute 返回结果重复请求只会增加一堆冲突日志。我的排查路径是固定的# 1. 看实例的 task_state 和 vm_state openstack server show 实例UUID -c id -c status -c task_state -c vm_state正常情况下删除流程中 vm_state 会被置成 DELETEDtask_state 是 deleting。如果这两个字段停留在这里不动说明 nova-compute 在处理时卡住了。第二步是到计算节点看日志我这边是 Kolla-Ansible 部署的看容器日志# systemd 部署一般看 /var/log/nova/nova-compute.log # Kolla 容器化部署一般看 /var/log/containers/nova/nova-compute.log grep -i error\|traceback /var/log/containers/nova/nova-compute.log | tail -n 50日志一般会明确给出原因最常见的是卷 detach 超时、libvirt 连接异常、网络清理时 Neutron agent 响应超时。然后到计算节点检查 domain 是否还活着virsh list --all | grep 实例UUID如果 domain 已经不在了但数据库里还卡着 DELETING说明实例底层的计算资源已经释放只是上层流程没走完。此时可以尝试把实例状态重置为 active再重新触发删除nova reset-state --active 实例UUID openstack server delete 实例UUID这个操作只用于把卡死的状态拨回可删除状态不是让一个已经消失的实例复活实际使用时要确认底层确实没有残留资源。如果 domain 还在那就先要决定是否强制清理 domain再考虑上层重置顺序不能反否则数据库刚刚标记删除底层 domain 又立刻报错。4.2 PAUSED 实例在宿主机重启后的尴尬处境有一次宿主机因为内核 panic 意外重启重启后我们发现上面有几台 PAUSED 状态的实例全部变成了 ERROR。原因前面说过Pause 的整个现场都在宿主机内存里电源一断内存清零libvirt 清单里也没有这些 domainNova 服务恢复后面对数据库里的 PAUSED 状态和实际不存在的 domain只能打成 ERROR。这种情况没有优雅的恢复手段。内存镜像都没了不可能靠 Nova 自动把它“unpause”回来。我的处理方案是和业务方确认这些实例的用途和数据位置。如果是无状态应用比如临时 Web 服务直接删除重建。如果挂载了卷可以先 detach 卷再用其他实例挂载读取关键数据。不尝试用nova reset-state --active把它救成可用状态因为内部进程现场已经破坏暴力恢复只会得到一台状态正常但客户机系统可能受损的“僵尸机”。这个案例也让我坚定了两条原则宿主机重启窗口前不允许任何 PAUSED 实例存在Pause 只能用于短时间暂停任何跨越硬件维护的计划都应该用 Suspend 或正常关机。4.3 卷和浮动 IP 残留删除后最容易被忽略的资源漏网删除实例后卷残留和端口残留是两大高频问题。卷残留我在第 2 章提过这里补充一个识别方法。当我拿到一个已经没有对应实例的卷时会用下面的命令确认它是否成了孤儿openstack volume show 卷ID -c status -c attachments -c bootable如果attachments为空status是 available那这个卷就处于无人认领状态。是否删除取决于团队的数据保留策略但至少周报里应该出现“本周新增孤儿卷数量”这个指标否则存储膨胀就是这么一天天堆出来的。端口残留的表现则更隐蔽。实例删了但 Neutron 的 port 记录还在IP 被占用。排查方法openstack port list --device-id 实例UUID openstack port show portID -c fixed_ips -c device_id -c status如果发现残留 port可以选择直接删除或者把 port 释放出来。浮动 IP 的回收也类似确认它已经解绑后如果不再需要就openstack floating ip delete IP。这里的经验是删除实例后的 5 分钟巡检比事后一周发现 IP 冲突再去排查要划算得多。4.4 慎用 reset-state它能救场也能制造更大问题nova reset-state在运维社区里名声不太好因为它能把数据库里的状态强行改成 active 或 error。我见过有人把真正还在运行的实例 reset 成 error然后再配合其他误操作让一个健康的业务实例直接消失。这个命令本身没有问题问题在于使用它的人没有先确认底层资源状态。我这里给出一个相对安全的执行清单先通过virsh list --all确认 domain 是否存在。再通过日志确认 nova-compute 是否已经对该实例完成清理。最后才考虑用 reset-state 重置数据库状态。一旦 reset 后发现问题立刻停止后续操作优先备份卷和端口配置。我自己只在两种情况下用它一种是卡在 DELETING 但 domain 已清理完毕重置后重新 delete另一种是实例被错误标记为 error但底层实际正常重置成 active 后先做数据确认再处理。除此之外其他场景我都不会优先考虑。5. 生产决策经验什么时候删除什么时候暂停什么时候应该用别的5.1 用一张决策表选择实例动作我在给团队做操作规范时把实例动作选择流程做成了下面这张判断表每次不确定用什么操作时就按顺序过一遍。判断问题如果答案是“是”选择什么业务数据已确认可丢弃实例不再需要Terminate业务需要暂停几分钟到 2 小时且不允许冷启动Pause宿主机马上要重启或维护实例需要跨重启保留Suspend 或 Stop实例长期不用但可能以后还要用想省计算资源Shelve 或 Stop实例状态异常且无法正常删除定位后 force-delete实例只是临时下线几天之后还会继续跑Stop这个表没有覆盖所有情况但能覆盖 80% 的日常场景。核心逻辑是不要只看“现在要不要它跑”还要看“它之后还要不要回来”“宿主机会不会重启”“数据和资源要不要保留”。5.2 我在维护窗口里的几个固定习惯最后讲几个我这些年养成的运维习惯算是踩坑总结出来的不一定适合所有团队但至少可以参考。删除实例前我一定先执行 stop然后检查状态确实变成 SHUTOFF再执行 delete。这一步对客户机内部的数据库类应用尤其重要能避免不少“断电式删除”的投诉。批处理实例时脚本必须加日志和失败兜底。一个简单的例子for id in $(openstack server list --status SHUTOFF -f value -c ID); do echo $(date %F %T) delete $id openstack server delete $id echo $id ok || echo $id failed done脚本虽然简单但每次删除前都会把实例 ID 和设备状态打出来万一删错了能回溯。千万别在循环里直接写openstack server delete $(openstack server list -c ID -f value)这种没有任何确认和日志的链条一旦列表里混入不该删的实例后悔都来不及。Pause 的使用范围我会控制得很严格只用于已经确认过内存资源和宿主机稳定性的短时操作。跨宿主机维护的场景我会提前把 PAUSED 实例全部清理掉宁可多花几分钟做 Suspend也不让任何一台 PAUSED 虚机留在即将重启的计算节点上。关于卷和网络资源我要求每周至少跑一次残留资源检查把 orphan 卷列表、无主端口列表发出来。这件事不麻烦但能避免很多存储和 IP 分配层面的隐性故障。这些年和 OpenStack 打交道下来我最深的体会是虚拟化平台的操作本身都不难难的是分清每个操作的边界和代价。Terminate 是终局Pause 是短时冻结Suspend 是持久化暂停Stop 是可恢复下线。把这几个动作想在前面比等故障发生了再去研究日志要省出的时间和精力多得多。
