oVirt虚拟机数量没有硬性上限，真正卡住你的是宿主机CPU、内存、存储IOPS和数据库性能这四块短板。多数生产环境在300-500台虚拟机时就会遇到管理端响应变慢，但通过合理架构和参数调优,上千台也是可行的。
oVirt虚拟机数量上限到底由什么决定
很多人上来就问“上限是多少”，其实这个问题本身就不太严谨，oVirt作为一款开源的虚拟化平台，本质上没有在代码里写死“最多只能跑多少台虚拟机”，你看到的那些性能瓶颈,全部来自物理资源的消耗和组件之间的通讯效率。
关键瓶颈集中在三个层面：
- oVirt Engine（管理端）：所有虚拟机的创建、迁移、调度指令都经过它,PostgreSQL数据库的读写性能直接决定了管理操作的流畅度。
- 宿主机（Hypervisor）：每台物理机上的CPU核心数、内存容量、磁盘队列深度,限制了单机可承载的虚拟机密度。
- 存储后端：不管是NFS还是iSCSI,存储系统的IOPS和延迟决定了虚拟机磁盘读写能否跟上。
行业共识认为，当虚拟机数量超过500台时，你最先感受到的不是计算资源不够，而是管理操作卡顿点个“新建虚拟机”要等好几秒,批量迁移时任务排队。
为什么有人说200台就卡，有人跑到1000台没事
这就要看你的使用场景了，如果你用oVirt跑的是测试开发环境，每台虚拟机只分1核1G内存，空闲时CPU占用率不到5%，那单台宿主机跑个三四十台毫无压力,整个集群跑上千台也不稀奇。
但如果是生产环境，每台虚拟机都在持续处理业务请求，磁盘IOPS打满，网络吞吐持续高位，那情况就完全不同了，业内专家指出，生产环境下单台宿主机建议控制在8-15台虚拟机，这样既保证性能隔离,又避免单点故障影响面过大。
如何优化提升oVirt虚拟机承载量，从管理端下手
管理端是最容易被忽略的瓶颈，很多运维人员拼命加宿主机，结果发现虚拟机越多，Engine越慢,最后在Web界面操作都成了煎熬。
第一步：给PostgreSQL数据库减肥
Engine的所有状态信息都存在数据库里，虚拟机每秒钟上报的心跳、CPU使用率、网络流量都会写入数据库，时间一长,表数据膨胀得厉害。
你要做的，是开启数据库的自动清理（autovacuum），并且调高清理频率，默认配置在虚拟机数量超过300台时明显不够用,操作路径如下：
su - postgres
psql -c "ALTER SYSTEM SET autovacuum_vacuum_scale_factor = 0.01;"
psql -c "ALTER SYSTEM SET autovacuum_analyze_scale_factor = 0.005;"
psql -c "ALTER SYSTEM SET autovacuum_naptime = '30s';"
systemctl restart postgresql把Engine所在虚拟机的磁盘换成SSD，这一点立竿见影，数据库随机读写性能提升后,你会发现Web界面的响应速度快了一个量级。
第二步：调整Engine的JVM内存参数
Engine本身是一个Java应用，JVM堆内存默认只有1G，虚拟机数量超过200台后，这个配置就会频繁触发垃圾回收,表现为界面假死。
编辑/etc/ovirt-engine/engine.conf.d/10-set-java-opts.conf文件：
ENGINE_HEAP_SIZE="-Xms4096M -Xmx8192M"改完重启服务：
systemctl restart ovirt-engine至于要不要加到16G甚至更高，取决于你的总虚拟机数量级。每增加300台虚拟机，建议JVM堆内存增加2G，别贪多,太大反而会导致垃圾回收停顿时间变长。
宿主机层的优化，挖掘单机潜力
很多人在搭建集群时，习惯把宿主机的CPU和内存全部分配给虚拟机，这是典型的“寅吃卯粮”做法，一台物理机如果CPU使用率长期超过80%，虚拟机性能会急剧下降，因为CPU的调度延迟变大,虚拟机内部的线程等待时间暴涨。
发挥CPU的NUMA亲和性优势
现在的物理机基本都是多路CPU，每个CPU对应一组内存通道，如果虚拟机使用的内存在远端NUMA节点上,内存访问延迟会显著增加。
oVirt提供了NUMA亲和性的配置入口，在集群设置里，把NUMA开启，然后根据虚拟机的性能需求，划分到不同的NUMA节点上，这样做的好处是，虚拟机访问本地内存，延迟可以降低20%-40%。
合理配置CPU热插拔与内存气球
在生产环境，我给客户的建议是：一台宿主机上，CPU超配比例控制在2-4倍
，比如一台物理机有32个物理核心，那就别分配超过64个vCPU给虚拟机，内存超配则谨慎得多，内存气球（Memory Balloon）虽然能提高密度，但也可能导致虚拟机内部OOM,生产环境建议关闭。
存储层面的优化，决定虚拟机的“飞轮”能转多快
虚拟机的磁盘性能，几乎决定了整个平台的体验上限，当你跑到300台虚拟机以上时,存储在性能瓶颈中的占比往往是最大的。
从NFS切换为iSCSI或FC
NFS在虚拟机数量少的时候，配置简单、管理方便，但虚拟密度上来之后，NFS协议的锁机制会成为严重的性能瓶颈，你可以把存储后端切换到iSCSI或FC SAN，配合oVirt的多路径（Multipath）配置,获得更好的并发访问能力。
给存储设置QoS，防止“噪声邻居”
当几十台虚拟机共享同一个存储LUN时，一台疯狂读写磁盘的虚拟机，会拖累所有邻居，解决办法是在oVirt的存储域上设置QoS策略，具体路径：存储 -> 存储域 -> QoS，给虚拟机的磁盘设置IOPS上限和吞吐量上限，这样就算有人跑了个全量备份,其他虚拟机的磁盘性能也不会被拉垮。
网络层面的调优，别让虚拟交换机拖后腿
虚拟机间的流量在虚拟交换机内部转发，几乎不消耗物理网卡资源，但一旦涉及外部通信,物理网卡的带宽就成了关键。
多块物理网卡绑定成Bond，配置为balance-slb模式，让oVirt的虚拟网络流量在多块网卡间动态均衡，如果你用的是10G网络，建议把虚拟机的vNIC多队列开启，让多个CPU核心分担网卡中断处理,这样单台虚拟机的网络吞吐量能翻倍。
生产环境ovirt虚拟机数量规划与实际案例对比
为了让这个概念更清晰,我用一个表格来对比不同规模下的配置要求：
| 虚拟机规模 | 宿主机需求 | 存储要求 | Engine配置 |
|---|---|---|---|
| 50台以下 | 4台双路10核，128G内存 | 千兆网络，普通SATA阵列 | 默认配置即可 |
| 100-300台 | 6台双路16核，256G内存 | 万兆网络，SSD缓存 | 调大JVM堆，优化数据库 |
| 300-1000台 | 10台以上双路16核，512G内存 | 全闪存阵列或分布式存储 | 独立高性能数据库节点 |
很多国内企业在做虚拟化改造时，一开始只规划了100台的规模，结果业务增长超出预期，就只能中途扩容，每一次扩容都涉及存储迁移、网络割接，操作风险不可忽视，倒不如前期把基础架构的余量留足，多花的那点预算,平摊到三年使用周期里并不起眼。
关于ovirt虚拟机数量上限的常见疑问
ovirt能跑几千台虚拟机吗，会不会直接崩溃
能跑，但管理端的压力会非常大，当虚拟机数量过千，Engine的数据库写入量剧增，你可能会碰到任务队列堵塞、主机监控数据延迟等状况，解决办法是把Engine拆分成多级架构，用额外的监控工具分担数据采集压力，不过对于绝大多数企业来说，把负载分散到多个oVirt环境或者配合其他多云管理平台,会是更省心的做法。
相比商业虚拟化方案，ovirt在大规模场景下有多大差距
差距主要体现在管理的便捷性和部分高级功能上，比如内存去重、跨站点容灾的自动化编排，但oVirt在计算性能上并不输太多，尤其是配合优化的存储和网络配置后，差距并不明显，如果你的成本预算敏感，技术团队又有一点的Linux基础,oVirt完全够用。
怎么判断我的平台该扩容宿主机了，看哪些指标
不要等虚拟机卡了才看指标，推荐在运维监控系统（比如Zabbix或Grafana）里盯死三个数据：宿主机CPU就绪时间（CPU Ready）、存储延迟、Engine响应时间，CPU Ready超过10%，说明CPU超配太狠；存储延迟超过20ms，虚拟机IO性能会让你崩溃；Engine界面点击操作响应超过5秒,就该按前面说的方法调优了。
oVirt虚拟机数量能否满足你的业务需求，关键在于你是否用心经营它的每一层架构，管理端优化消除调度瓶颈，宿主机合理超配挖掘算力，存储网络联动保障数据通路这三件事做扎实了，上千台的规模完全可以驾驭，如果只堆硬件不管配置,再强的服务器也会被糟糕的架构拖进泥潭。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/631108.html
