nova虚拟机大小调整的本质，就是给实例换一个flavor（规格），通过resize命令让OpenStack重新调度宿主机资源，CPU、内存、磁盘配额都会跟着变化，性能影响主要来自迁移方式、宿主机剩余容量和存储后端。
nova虚拟机大小调整的操作步骤：resize命令详解
调整虚拟机大小在OpenStack里叫resize,操作路径比大多数人想象中简单，核心就三步：选好新flavor、执行resize、确认结果，下面直接给命令。
先查看当前实例的规格和所在宿主机：
openstack server show <server-id> | grep -E "flavor|OS-EXT-SRV-ATTR:host"
再列出所有可用的flavor,确定目标规格的名字或ID：
openstack flavor list
执行调整：
openstack server resize --flavor <flavor-name> <server-name>
执行完成后实例会进入RESIZE状态，等待OpenStack调度器把虚拟机迁移到能容纳新规格的宿主机，这个过程不是瞬间完成的，耗时取决于磁盘大小和存储类型，迁移完以后，实例状态会变成VERIFY_RESIZE，这时候需要你手动确认：
openstack server resize confirm <server-name>
如果想反悔,可以用revert回退到原来的flavor：
openstack server resize revert <server-name>
如果不太习惯命令行,Horizon界面的实例详情页里也有“调整大小”按钮，选好新规格后点击确认就行，本质上调用的是同一个API。
有一点容易被忽略：resize过程中虚拟机会关机，业务会短暂中断，所以生产环境里，一般会提前做灰度或选择低峰期操作，如果你用的是Heat编排模板，改flavor参数后做stack update也能触发resize，但过程同样有停机窗口。
nova resize 对性能的影响：CPU、内存和磁盘的变化
很多人以为换了更大的flavor,性能就是线性提升，实际不是，性能影响取决于三个层面：新宿主机的余量、存储后端形态、迁移后网络路径。
CPU：vCPU翻倍，性能不一定翻倍
flavor里的vCPU数直接对应宿主机上分配的虚拟CPU,对于计算密集型应用，比如编译、视频转码，增加vCPU通常能缩短任务时间，但有个前提：目标宿主机有足够的物理CPU核心，并且超配比不高。
如果宿主机已经跑满了其他虚拟机,你的vCPU再多，也只会换来更多时间片争抢，行业共识认为，生产环境CPU超配比控制在4:1以内，否则平均CPU等待时间会明显增加，所以resize之前，最好先检查目标宿主机的vcpu_used与vcpu_total，避免挤在过载的机器上。
内存：物理内存足够才安全
内存扩容比CPU更敏感,OpenStack允许内存超配，默认情况下，如果目标宿主机物理内存不够，Nova会尝试用swap或者KSM页面合并来“骗”过内存分配，结果就是，你的实例看着有64GB内存，实际可能有一大部分住在swap区，性能会断崖式下降。
这种情况下,最直接的排查方式是在实例内部跑一个free -h，看swap用量是否异常，真正靠谱的做法，是确认目标宿主机剩余物理内存足够再resize，或者用Nova的host aggregate隔离几个内存充足的高配宿主机，专门跑大内存实例。
磁盘：本地磁盘拷贝决定停机时长
磁盘是resize性能影响里最重的一部分,如果实例用的是本地硬盘（ephemeral disk），resize会触发冷迁移，系统先把整块根磁盘复制到新宿主机的存储上，拷完再启动虚拟机，磁盘越大，停机时间越长，一个500GB的本地盘实例，在千兆网络下可能需要十几分钟。
反过来,如果使用了共享存储，比如Ceph、共享LVM，数据本身不需要复制，Nova只要在新宿主机上重新定义一块指向相同后端存储的虚拟磁盘，然后启动实例就行，这个过程中的停机时间很短，通常几十秒。
判断resize对业务影响大不大,先看存储后端是什么，如果业务对可用性要求高，建议从一开始就把云硬盘（Cinder）和共享存储作为主存储，避免本地盘带来的迁移伤痛。
网络：迁移后流量路径可能变长
这个点很多人不留意,虚拟机从宿主机A迁到宿主机B之后，如果环境里用的是分布式虚拟路由器（DVR），东西向流量还能直线转发；如果用的是传统legacy网络模式，流量可能要绕道到网络节点，增加一跳或两跳时延。
运维实践里,我们有遇到过resize之后业务延迟从0.5ms涨到3ms的情况，最后定位到就是网络架构问题，所以大规格迁移之后，最好重新测一遍ping或TCP建连时延，确认网络路径没有意外变长。
resize后性能变差的排查思路：先看宿主机，再看存储
如果你执行完resize确认后,业务反而变卡了，别急着怀疑OpenStack给错了资源，按照下面步骤定位：
- 登录实例内部,执行
top、free -m、iostat -x 1，看是CPU占用高、内存不足，还是磁盘等待高。 - 在宿主机上执行
virsh list确认实例所在宿主机ID，再用virsh vcpupin <domain>检查vCPU是否绑定到物理核。 - 对比原宿主机和现宿主机的磁盘类型,原来SSD、现在机械盘的话，IO性能必然下降。
- 检查宿主机内存超配状态。
openstack host show <host>能看到memory_free，如果接近0，说明新宿主机内存很紧张。
多数情况下,resize后性能变差的根因就是宿主机的剩余资源比你预期得少，这时候可以手动迁移到另一个可用域，或者找一台负载更低的宿主机作为主宿主机，重新做一次resize。
调整nova虚拟机大小时的替代方案：快照+重建 vs 热迁移
resize并非唯一改大小的方法,有时候用替代方案更合适。
- 快照+重建：先对实例做快照，再用新flavor从快照构建新实例，这种方式不受原宿主机剩余资源限制，还可以顺便换新镜像、改磁盘类型，缺点是停机时间较长，快照和重建期间服务不可用。
- 热迁移（live migrate）：不换flavor，只换宿主机，如果只是想让实例从一个高负载宿主机换到低负载宿主机，热迁移零停机，但规格不变，热迁移不能替代调整大小。
对比一下两者适应用场景：
| 方式 | 停机时间 | 能否换规格 | 适用场景 |
|---|---|---|---|
| resize（冷迁移） | 中等，分钟级 | 可以 | 长期扩容、升级配置 |
| 快照+重建 | 长，取决于快照大小 | 可以 | 更换镜像、重建环境 |
| 热迁移 | 零停机 | 否 | 宿主机维护、负载均衡 |
如果只是想临时性能测试,不建议直接调大生产实例，更稳妥的方案是先克隆一份环境，在测试环境里试好新规格和网络性能，再对生产做resize。
常见问题
Q1：nova resize 需要停机多久？
取决于磁盘大小和后端存储,使用本地磁盘时，停机时间等于磁盘拷贝到新宿主机的耗时，几百GB数据可能需要数分钟到十几分钟；共享存储场景下，停机时间通常只有几十秒，因为数据无需复制，只重建虚拟设备。
Q2：nova resize 后性能变差，是资源分配错误吗？
不一定,最常见原因是目标宿主机已运行大量实例，CPU或内存超配比过高，导致实际资源争抢严重；其次需要检查存储后端是否从SSD换成了机械盘，用openstack host show查看目标宿主机资源余量，再对比实例内的top和iostat，就能定位瓶颈。
Q3：能把虚拟机大小调小吗？
可以,通过resize到更小的flavor降低配额，调小内存前要确认实例内存占用不高，避免切换后触发OOM，调小磁盘目前在Nova里默认不支持，只能通过快照重建新实例来实现，或者在块存储层面做缩容，但这属于Cinder的云硬盘操作，与Nova的resize逻辑无关。