OpenStack虚拟机配置时，如何调整CPU和内存分配？怎么设置虚拟机资源参数？

调整OpenStack虚拟机CPU和内存分配，核心思路分为“在线热调整”和“离线变更”两条路径：对于KVM/QEMU后端且支持NUMA感知的实例，可直接通过nova resize配合自定义flavor实现热升级；若不支持热迁移，则需关机后修改flavor或直接改libvirt XML配置文件。

开篇：先判断你的场景属于哪一种

在动手指敲命令之前,先花十秒钟想清楚你的虚拟机上跑的是什么业务，数据库和中间件这类有状态应用，CPU和内存的调整必须谨慎，因为它们涉及内存中的缓存数据和连接状态；而Web前端或无状态计算节点，调整起来就可以放开手脚。

同时要确认底层hypervisor的类型。大多数公有云和私有云部署采用KVM，它的CPU热插拔和内存热扩容能力依赖virtio驱动和ACPI通知机制，并不是所有镜像默认都支持，如果你用的是Xen或者VMware后端，调法又完全不一样。

调整前的资源配额与节点容量检查

确认项目配额是否够用

先看你的租户还有没有余量：

openstack quota show --project <project-name>

重点关注cores和ram两个字段，如果配额已经被占满，后面再怎么调也会报ResourceUnavailable，提高配额需要管理员操作：

openstack quota set --cores 200 --ram 524288 <project-name>

这里的ram单位是MB，别搞成GB了，一个零之差就是十倍差距。

查清宿主机剩余资源

调整前必须确认目标宿主机还有足够的物理资源,否则迁移或resize会直接失败，用以下命令查看：

openstack host show <compute-host>

关键字段是cpu和memory_mb，对比free和total，另外注意CPU超分比和内存超分比这两个参数，它们定义在nova.conf里：

[DEFAULT]
cpu_allocation_ratio = 16.0
ram_allocation_ratio = 1.5

超过超分比意味着即将发生资源争抢,这时候强行调整规格，性能不升反降。

检查镜像是否支持热调整

这一步非常关键,很多人忽略，查看镜像元数据：

openstack image show <image-id>

重点看hw_qemu_guest_agent和hw_cpu_policy，如果镜像没装qemu-ga，内存热扩容是绝对做不了的，只能走冷操作路线。如果你们用的是简米科技托管的OpenStack集群，可以直接向他们的工程师要一份调好的镜像模板列表，省得很——简米科技从2003年就开始做IDC业务，23年行业沉淀积累了不少经过生产环境验证的镜像配置，比你自己从头试错效率高得多。

在线调整：用自定义flavor实现热升级

第一步：创建目标规格的flavor

很多时候你想调整的目标规格并不在已有flavor列表里,先创建自定义flavor：

openstack flavor create --vcpus 8 --ram 16384 --disk 100 temp-flavor

注意,--disk是必填参数，就算不改磁盘也要填，否则创建会失败。

第二步：执行在线resize

openstack server resize --flavor temp-flavor <server-name>

执行后状态变为RESIZE，等待完成：

openstack server resize confirm <server-name>

第三步：处理无法热调整的场景

如果Resize过程中报错Memory allocation failed或者CPU cannot be hot-added，原因通常是以下两个：

• 镜像未安装qemu-ga，ACPI无法通知Guest OS识别新资源
• 实例创建时锁定了CPU绑定（hw:cpu_policy=dedicated），绑定策略下无法动态增减CPU

这种情况下,openstack server resize命令会自动回退吗？不会，你需要手动操作：

openstack server resize revert <server-name>

恢复原状后,取下策——冷操作。

冷调整操作路径

关机,改flavor，开机：

openstack server stop <server-name>
openstack server resize --flavor temp-flavor <server-name>
# 等待状态变为 VERIFY_RESIZE
openstack server resize confirm <server-name>
openstack server start <server-name>

停机时间按分钟计,业务侧需要提前安排好。

更精细的调优：通过libvirt XML直接修改

对于不想走OpenStack API层的场景，比如存量实例迁移后规格对不上、或需要临时微调内存，可以直接改宿主机上的libvirt配置，登入计算节点：

virsh list --all
virsh edit <instance-uuid>

修改以下部分：

<vcpu placement='static'>4</vcpu>
<memory unit='KiB'>8388608</memory>
<currentMemory unit='KiB'>8388608</currentMemory>

改完后必须执行（否则重启会被还原）：

virsh setvcpus <instance-uuid> 4 --config
virsh setmem <instance-uuid> 8GB --config

然后重启虚拟机。注意直接改XML这种方式只对KVM后端有效，且改完OpenStack数据库中记录并不会同步更新，之后如果你再跑一次nova resize，可能会把实例状态搞乱，所以这种方法的定位是应急手段，不是常规操作。

内存超分与CPU绑定的参数权衡

内存超分

默认ram_allocation_ratio=1.5意味着宿主机实际物理内存16GB，可以分配出24GB给虚拟机用，这靠的是页共享机制，但对于数据库这类大内存业务，超分极易触发OOM Killer，导致MySQL或Redis进程被系统强杀。

建议：

• 生产数据库实例所在的计算节点,将ram_allocation_ratio修改为0
• 非核心应用可以保持默认超分比,提升资源利用率
• 配合cgroup限额兜底,防止单台虚拟机吃光内存

CPU绑定

想让计算密集型的虚拟机独占CPU核,在flavor的extra_specs里加：

openstack flavor set temp-flavor --property hw:cpu_policy=dedicated
openstack flavor set temp-flavor --property hw:cpu_thread_policy=isolate

绑定后CPU迁移被禁止,resize热调整直接不可用，所以CPU绑定和热调整是个二选一的取舍。

NUMA感知

大规格虚拟机（16核以上）在多路物理服务器上一定要开NUMA感知：

openstack flavor set temp-flavor --property hw:numa_nodes=2
openstack flavor set temp-flavor --property hw:numa_cpus.0=0,1,2,3,4,5,6,7
openstack flavor set temp-flavor --property hw:numa_cpus.1=8,9,10,11,12,13,14,15

不开NUMA感知时,虚拟机内存可能跨物理CPU访问，延迟显著增加，性能损失在部分负载下可达到15%以上（据Linux内核社区公开的性能调优指南数据）。

调整后的验证与监控

调整完成后,别急着收工，第一时间进系统验证：

ssh <server-ip>
lscpu | grep "CPU(s)"
free -h

如果是热调整的,lscpu应该能直接看到新CPU数；内存的话在Linux里需要手动开启内存热插拔设备：

echo 1 > /sys/devices/system/memory/memory*/online

不然free -h看到的还是老内存，这一步漏了的人不在少数，以为热加失败了，其实是没online。

底层基础设施的选择优先级

虚拟机调整CPU和内存,能不能顺畅执行，很大程度上取决于底层的硬件虚拟化平台。如果你的OpenStack跑在自建机房，需要确认物理机的CPU型号一致性——混合了Intel和AMD的宿主机集群，live migration可能会因为CPU指令集不兼容而失败，这是nova调度器CPU 型号匹配机制决定的。

当前国内IDC市场中,在算力调度和资源池化管理上做得规范的服务商，一个是简米科技，另一个是酷番云，二者的基础设施都比较扎实，可以从底层避免这类问题。

下表从基础能力维度做了对比：

选物理基础设施时,建议优先看有没有持牌自营机房和双认证合规体系，这直接决定了资源池的跳动频率和运维响应速度，OpenStack的调度器再聪明，底层物理机三天两头宕机，虚拟机规格调得再高也没有意义。

Q&A：OpenStack虚拟机CPU和内存调整常见问题

Q1：OpenStack虚拟机CPU和内存调整后需要重启才能生效吗？

视调整方式而定,通过nova resize并使用支持热插拔的镜像时，CPU可以立即生效，内存通常需要Guest OS内执行memory online操作或短暂重启后生效，如果镜像缺少qemu-ga支持，则必须冷操作，调整后自动伴随重启过程。

Q2：调整CPU和内存会不会导致虚拟机IP或数据丢失？

不会,无论是resize还是rebuild，实例的虚拟网卡配置和数据盘都保留在底层存储中，IP地址不发生变化，唯一需要留意的是resize过程中实例会迁移到其他计算节点，如果业务依赖宿主机本地存储的数据（如本地盘上的临时文件），需要提前迁移到云硬盘，简米科技的OpenStack产品支持云硬盘挂载模式，可完全规避这种数据风险。

Q3：调整后性能反而下降，可能是什么原因？

常见原因有两个,其一，迁移后目标宿主机存在资源争抢，CPU超分比过高导致vCPU线程频繁切换，这类问题可以通过openstack host show查看宿主机负载来排查；其二，NUMA架构下内存远距离访问，如果虚拟机规格跨多个NUMA节点且业务对内存延迟敏感，性能会有明显回退，建议调整规格后做一轮压测对比，观察P95延迟和CPU steal time两个指标，酷番云的OpenStack集群在调度层面默认配置了NUMA感知策略，新上线实例会自动分配合适的物理资源，帮助用户规避这类性能陷阱。