这两年不少团队在租来的物理机上自己搭私有云，选 OpenStack 的少了——说白了， OpenStack 那套控制面（Keystone、Nova、Neutron、Cinder、Glance 各管一摊）对十人以下的运维组太重，装一次要一周，出一次故障要查半天日志链。OpenNebula 的 oned 就一个守护进程，Ruby 写的探针加一批 shell 脚本，五台宿主机以内的集群，一个熟手两天能上线。
但我见过太多"装完就翻车"的案例：跑了一个月，宿主机内存莫名其妙吃满、批量开二十台虚拟机要等六分钟、某天早上所有 VM 突然全变成 paused 状态。这些故障几乎没有一个是 OpenNebula 本身的 bug，全是宿主机容量规划这一步没算账。本文只讲一件事——租来的裸金属，怎么配才不翻车，分四本账：内存预留、镜像存储、CPU 调度、网络与前端。
先把结论摆在这里，赶时间的人看到这段就够了：
新上手的人最容易犯的错，就是把 free -g 看到的数字当成可分配量。128G 的机器，能真正分给 VM 的大约 105–110G，剩下的被四样东西吃掉。
一台最小化安装的 Ubuntu 22.04 或者 Rocky 9，装完 libvirtd、QEMU、OpenNebula 的节点包之后，常驻内存约 700MB–1.2G（预估）。这里面还包括 OpenNebula 的监控探针——它本质上是一批周期性执行的采集脚本，每次跑起来瞬时几十 MB，如果探针周期设得太密（/etc/one/monitord.conf 里的采集间隔），叠加起来就不是一个可以忽略的数字。再加 node_exporter、SSH 会话、日志采集 agent，这一份按 1.5G 打底比较稳。
VM 申请 4G，宿主机实际消耗不是 4G。QEMU 进程本身有代码段、有 virtqueue 的共享内存、有 vhost-net / vhost-scsi 内核线程的栈，通常每台的额外开销在 80–250MB（预估），vCPU 越多、挂的磁盘网卡越多就越高。这个数字单看很小，但乘上密度就吓人：四十台 VM 就是 3–10G（预估）。
页表、IOMMU 页表、KVM 的 mmu 影子页结构，这些都算在宿主机的内存账上。大内存 VM（比如 64G 的）尤其明显，二级页表本身就能占掉几百 MB（预估）。这一份按 0.5–1G 估。
如果 VM 的磁盘走 cache=writeback，宿主机的 Linux 会拿空闲内存给 guest 的读写做缓存，几十 GB 几分钟就能吃掉，而且它看起来"可回收"，实际上在内存压力下回收是要时间的，超卖场景下这几秒就足够触发 OOM。想让内存可预测，直接给数据盘设 CACHE="none"（OpenNebula 里是磁盘的 CACHE 属性，也可以在 vmm_exec_kvm.conf 里设 DISK_CACHE 做全局默认），走 O_DIRECT，缓存让 guest 自己的内核管。
加总：8G 固定开销（1.5 + QEMU 平均 40 台 ×200MB ≈ 6.5G 已经算进去了，取个整），再留 5% 的水位。128G 的宿主机，填 RESERVED_MEM = 8388608（单位 KB，即 8G），可分配量就落在 105–110G。填法： onehost update 打开主机模板，加一行 RESERVED_MEM，探针下一次上报时生效。宿主机再配 2–4G swap 兜底，但别把 swap 当内存用——swap 一开，OOM 就变成"卡到没法用"，那比直接死还难排查。
超卖这件事没有标准答案，但有清晰的判断线。我的分界线是：宿主机上只要有一台 VM 内存超过 16G 且跑的是有状态服务（数据库、ES、Redis、Java 大堆），这台宿主机就 1:1 不超卖。剩下的 Web、中间件、CI 构建机、开发测试机，1:1.5 可以接受，1:2 是上限。
理由是超卖的前提假设——"大部分 VM 不会同时用满申请的内存"——在有状态服务上根本不成立。MySQL 的 InnoDB buffer pool 是预分配后常驻，Redis 的 maxmemory 用满就是实打实的 RSS，JVM 的 -Xmx 一旦触顶也不会主动归还。这类 VM 的"申请量"和"使用量"几乎相等，超卖它们等于裸奔。
三种常见的内存节省手段，各有各的代价，别只看收益：
balloon（virtio_balloon）：需要 guest 装驱动，回收有延迟，而且压力来了它还没来得及回收，guest 内部自己先 OOM 了——死的是 guest 里的进程，不是宿主机上的 QEMU，这种故障表现是"数据库自己崩了"，非常具有误导性。
KSM（同页合并）：跑同一套模板镜像的 VM 之间能合并出 10–30% 的内存（预估），看起来很香。代价是 ksmd 内核线程持续扫描页表吃 CPU，而且它带来的侧信道问题在合规审计时会被挑出来。金融、政务这类场景我直接不开。
hugepage（大页）：2MB 或 1GB 大页能显著减少 TLB miss，对 32G 以上的大内存 VM，性能提升 5–15%（预估）是常见的。但大页是静态预留、不可换出，跟内存超卖天然互斥——开了大页就别超卖，这是硬约束，不是建议。
最后说 OOM 到底杀谁。内核 OOM killer 挑进程看的是 oom_score，RSS 越大分数越高。QEMU 进程的 RSS 基本等于它承载的 VM 内存，所以宿主机真打满时，被杀的几乎必然是你那台 32G 的数据库 VM，而不是旁边那台 512MB 的小工具机。想改这个优先级，两条路：一是给 libvirtd、sshd、监控 agent 在 systemd 单元里加 OOMScoreAdjust=-1000，让它们绝对不被杀；二是给关键 VM 的 QEMU 进程设 oom_score_adj=-500，牺牲掉非关键的。更省事的做法是给次要 VM 用 libvirt 的 memtune 设 hard_limit，把上限钉死。
OpenNebula 的 datastore 分三类，刚上手时没人分得清，但这是整个容量规划里最该搞明白的一组概念：
image datastore（IMAGE_DS）放注册进来的模板镜像，读写特征是"几乎只读、偶尔写入"，容量型需求；system datastore（SYSTEM_DS）放 VM 运行时的磁盘，读写特征是"随机写、要 IOPS"，性能型需求；还有个 files datastore（FILE_DS），放 kernel、ramdisk、context ISO 这类小文件，几十 GB 就够，不参与这场讨论。
开一台 VM 时，OpenNebula 的传输管理驱动（TM）会把镜像从 image datastore 克隆一份到 system datastore。这一步的代价取决于后端：SSH 驱动是整盘拷贝，Ceph 是快照加 COW 克隆。
假设模板镜像 20G，一次批量开 20 台。image 侧要吐出 400G 顺序读，system 侧要吞下 400G 顺序写，两边在同一块盘上抢磁头、抢队列。原本 40 秒能完成的单台克隆，实际能拖到 5–6 分钟（预估）。用户体验就是"点完开机去泡了杯咖啡回来还在转圈"。
image datastore 的容量是会自然膨胀的。每次 onevm disk-saveas、每次"另存为新镜像"、每次上传新版本模板，都留下一份几十 G 的文件，没人定期清理的话，半年就能把盘吃满。这时候如果 system datastore 跟它在同一个文件系统上，盘满的瞬间，运行中的 VM 写盘返回 ENOSPC，QEMU 会把 VM 置为 paused 状态。
这个故障的可怕之处在三处：宿主机没宕机、libvirt 里 VM 状态还是 running、监控的存活指标也还正常，但业务全断了。值班的人第一反应是查网络、查应用，等绕一圈回来发现是磁盘满，已经过去四十分钟。我处理过两次，两次都是这个路径。
物理分开是最干净的：image datastore 用大容量 HDD 或者廉价 SATA SSD（它只要求读带宽和容量），system datastore 用企业级 SSD、NVMe 或者 Ceph 的 SSD 池。预算实在紧，最低也要做分区隔离——同一块盘上划两个分区、两个挂载点，至少能保证 image 写满时 system 还有余量，VM 不会当场被暂停。目录级隔离（同一文件系统下放两个子目录）等于没隔离，别骗自己。
水位线：system datastore 至少留 20–30% 空闲，这部分要装快照增长、临时盘、冷迁移的中间文件；image datastore 留 15%（预估），主要是给镜像版本和回滚留余地。
镜像格式这件事，论坛上能吵三天，落到生产上其实就两句话：image datastore 里存 qcow2，system datastore 里落 raw。
qcow2 的好处是稀疏（40G 的模板实际可能只占 3G）、支持内部快照、支持 backing file 做秒级 COW 克隆。代价是中间多一层映射：默认的 cluster 是 64KB，每次往没分配过的 cluster 写入，要先更新 L2 表、再更新 refcount 表，等于一次 4K 写放大成三四次物理写。更麻烦的是快照链——每一层都是一次读回溯，链超过 5 层之后，4K 随机读的 IOPS 掉 30–50%（预估）很常见。
raw 的好处是直接：块设备（LVM 的 LV、Ceph 的 RBD）上的 raw 就是原生块，性能最好，也没有元数据损坏的风险。代价是不稀疏、没有内部快照（快照要靠 LVM 或 RBD 自己提供）。
性能差多少？同硬件上 raw 比 qcow2，4K 随机写通常高 8–20%（预估），顺序读写高 3–8%（预估）。坦白讲，这个差距在生产环境里远不如"快照链三年没压平"和"盘快满了"这两件事影响大。所以选 raw 的理由不是那 10% 的性能，而是可预测、好排错。
一是 qcow2 的元数据写，前面说了；二是快照链读放大，定期用 qemu-img commit 或者 rebase 把链压平，OpenNebula 里删掉磁盘快照不一定立即回收空间，要去 system datastore 里看实际占用对不对得上；三是格式转换，qemu-img convert 从 qcow2 转 raw 会把稀疏文件"撑实"，40G 的模板转出来就是 40G 落盘；四是克隆拷贝本身，SSH 驱动下 20G 镜像就是 20G 读加 20G 写。
转换的时机是这里的关键。一定要在"注册镜像"这一步之前把格式转好：本地 qemu-img convert -f qcow2 -O raw 转完，再把 raw 版注册进 image datastore。千万不要让宿主机在部署时现场转——20 台并发就是 40×20 = 800G 的额外写入，那块盘会当场卡死，而且你会看到一堆莫名其妙的部署超时。
选 datastore 后端比选磁盘型号重要得多，因为它决定了你能做什么、不能做什么。
最省事，门槛也最低。硬要求只有三条：oneadmin 用户到所有节点（包括它自己）的 SSH 免密；所有节点上 /var/lib/one/datastores/ 路径一致；image datastore 可以是 NFS 共享给所有节点读。缺点是克隆为整盘拷贝，20G 镜像就是 20G 传输加 20G 落盘；而且 VM 磁盘落在宿主机本地盘上，冷迁移（停机拷贝）可以，热迁移基本不支持。适合五台宿主机以内、镜像不超过 50G、能接受分钟级开机延迟的小集群——老实说，这个规模用 SSH 后端完全够，别一上来就上 Ceph。
NFS 或 GlusterFS 挂到所有节点，支持热迁移，配合 qcow2 的 backing file 还能做到秒级克隆。要求高了：共享存储自己必须高可用——NFS server 一挂，全集群的 VM 都写不了盘，这是把单点从宿主机挪到了存储上；网络 10G 起步；NFS 的 rsize/wsize 要调，sync 模式写会慢，async 模式掉电有丢数据风险。用之前先想清楚 NFS 那台机器挂了怎么办。
每个 VM 盘一个逻辑卷，性能最接近裸盘，raw 落在这里最舒服。要求：整块盘或整组 RAID 交给 LVM 做 VG，不要和系统盘共用一个 VG；VG 要留 10–20%（预估）给快照卷和元数据。这里有个专门的坑：LVM 的快照是 COW 卷，写满了会变成 Inactive 状态——快照失效还算小事，连带 VM 被暂停才是大事。所以 lvm.conf 里的 snapshot_autoextend_threshold 一定要开，让快照卷自动扩容。同样是本地盘，同样不支持跨机热迁移。
image 和 system 各建一个 pool，同一个集群、不同的 CRUSH rule：image 池放 HDD，system 池放 SSD 或 NVMe。部署走 RBD 快照加克隆，COW 机制下 40G 镜像开一台 VM 实测不到 3 秒（预估），体验完全是另一个级别。
但它的要求也最硬：MON 至少 3 个且必须是奇数；每节点 OSD 盘不少于 4 块；副本数 3 时可用容量只有裸容量的三分之一——12 块 4T 盘共 48T 裸容量，实际可用 16T，这个账无数人算错过；集群网络 2×10G 起步且要与业务网物理分开；每个 OSD 预留 2–4G 内存（预估）；OSD 的 WAL/DB 放 NVMe。集群最小 3 节点，2 节点的 Ceph 就是定时炸弹，别抱侥幸。
取舍判断：宿主机超过 8 台、必须要热迁移和自动故障恢复，才值得上 Ceph，它的运维成本至少要多半个人力；5 台以内用 SSH 加本地 SSD 就够了。
拿一万网络那档 E5-2698v4×2 说事：单颗 20 核 40 线程、2.2GHz 基频、50MB L3、135W，双路就是 40 个物理核、80 个逻辑核、2 个 NUMA 节点。
同一个物理核上的两个逻辑线程共享执行单元、共享 L1/L2、共享访存带宽，实测能带来的额外吞吐只有 15–30%（预估），不是 100%。如果按"80 个逻辑核分 80 个 vCPU"，等于按 1:1 卖给自己，但物理上只有 40 份执行资源，结果是 CPU ready 时间飙升——VM 里的进程明明想跑，却在等物理 CPU，应用侧表现为"负载不高但响应很慢"，这种症状最容易被误判成磁盘或网络问题。
我的算法：通用业务按物理核 ×1.5，数据库和高并发 Web 按物理核 ×1，开发测试和轻量容器按物理核 ×3 封顶。对应到 40 核双路，就是通用业务给 60 个 vCPU、数据库给 40 个、测试环境最多 120 个。怎么知道超了：CPU ready 超过 5%（预估阈值）就是明显超卖，virsh cpu-stats 能看，宿主机侧盯 load5 与核数的比值也对得上。
OpenNebula 里 CPU 的单位是"每核 100"，40 核的主机会报 TOTALCPU = 4000。要给宿主机留 2 个核的量，就写 RESERVED_CPU = 200。
双路机器上，一台 VM 的 vCPU 和内存如果跨了 NUMA 节点，大约一半的内存访问要走 QPI 到对面节点取，延迟高 40–60%（预估）。对数据库、高频交易、DPDK 这类负载，这是实打实的损失。OpenNebula 6.x 起支持在 VM 模板里写 NUMA_NODE（指定 MEMORY、TOTAL_CPUS、CPU）配合 PIN_POLICY（NONE / THREAD / CORE / SHARED / ISOLATED）来做绑核和 NUMA 亲和。
必须绑的情况：VM 内存超过单个 NUMA 节点内存的一半、跑低延迟数据库或 DPDK、要开 1G 大页、vCPU 数已经超过物理核数。
绑了反而更慢的情况：VM 很小（2–4 vCPU）但数量多、负载是突发型的。绑死之后调度器不能跨核腾挪，一台 4 vCPU 的 VM 峰值就只能吃它那 4 个核，隔壁三十个核在睡觉。还有一种自相矛盾的配置：开了 pinning 又开 CPU 超卖——绑核的前提是资源独占，你都绑死了还超卖，逻辑上是打架的。
折中做法：只对那 20% 的关键大 VM 绑核，剩下 80% 让 libvirt 自己调度。
OpenNebula 的调度是两步：先过滤，再排序。过滤看的是主机是否满足 VM 的 SCHED_REQUIREMENTS、内存 CPU 够不够、目标 datastore 容量够不够；排序看 SCHED_RANK 表达式，值最大的宿主机中标。写歪的地方通常就在这三步里。
第一种歪法：没设 RESERVED_MEM 和 RESERVED_CPU。探针报上来 128G 全空闲，调度器就真按 128G 去分，最后一台 VM 要么起不来，要么起来把宿主机拖进 OOM。这个前面讲过，不重复。
第二种歪法：rank 表达式的符号搞反。rank 是值越大越优先，所以想做均衡——把新 VM 摊到剩余资源最多的机器上，写成 SCHED_RANK = FREECPU + FREEMEMORY；想做打包——塞满一台再下一台，省电、留整机空位做维护，写成负的 SCHED_RANK = - (FREECPU + FREEMEMORY)。网上教程直接抄、版本对不上，最常见的现场症状就是"二十台 VM 全压在一台宿主机上，另外三台空得离谱"。
第三种歪法：只看内存不看 CPU。默认表达式里带 RUNNING_VMS 权重项，具体长什么样不同版本不完全一致，自己 cat /etc/one/sched.conf 确认，别照抄任何教程。内存还剩一半但 CPU 已经跑满的宿主机，在只比内存的 rank 下照样会被选中。
还有个隐蔽的：datastore 容量判断。调度时 system datastore 的剩余空间是按"镜像声明大小"算的，但部署过程里会先克隆再写入、还要给快照留位置，实际占用比声明的大。这就可能出现部署到一半失败，VM 卡在 boot 状态、system datastore 里留下一堆残骸。
排查办法很朴素：部署前 onehost show 看 MEMORY 和 CPU 的 TOTAL/USED/FREE 三项，再 onedatastore show 看容量，和你的预期对不上，问题一定出在 RESERVED_* 或者 rank 上。中小集群（4–10 台宿主机）我的默认建议是：均衡 rank + RESERVED_MEM 8G + RESERVED_CPU 200，别玩 packing，除非你明确要把电费省下来。
oned 加 MariaDB 加 Sunstone（Ruby 写的老前端）或 FireEdge（新前端），加起来的资源占用很小：几百台 VM 规模下 oned 常驻内存 300MB–1G（预估），整机 8C16G 就能跑得很舒服。oned 监听 2633 端口，Sunstone 走 9869。
但它的角色决定了它必须高可用。前端挂掉，已经在跑的 VM 完全不受影响——libvirt 在宿主机上自己跑，不依赖前端；挂掉的是新建、迁移、快照、监控、计量这些控制面操作。所以判断标准很直接：你能接受多久不能开新机器、不能做热迁移？十分钟以内能恢复（有完整的 DB 备份、/etc/one 配置备份、能重装），单前端可以接受；做不到就上双前端。
OpenNebula 6.x 起支持 leader/follower 的前端高可用（Raft 复制状态）。成本最低的方案是两台前端加一个 keepalived 的 VIP，MariaDB 做主从，故障切换分钟级。这里有个必须注意的点：MariaDB 的数据目录单独放 SSD，innodb_buffer_pool_size 给 2–4G（预估），定期 mysqldump 或 xtrabackup 备份——恢复前端其实不难，难的是 DB 里那几百台 VM 的状态记录丢了。
Linux bridge 是最轻的，每包处理开销在几微秒量级（预估）。VXLAN 就不一样了：每包要多封装 50 个字节（VXLAN 头 8 + UDP 头 8 + 外层 IP 头 20 + 外层以太头 14），MTU 必须压到 1450，或者物理网开 9000 巨帧，否则分片能吃掉 20–30% 的吞吐（预估）。10G 线速跑 VXLAN，软中断能占掉 4–8 个核（预估）——这就是很多人"网络一上 VXLAN，宿主机就莫名其妙变卡"的原因，CPU 不是被 VM 吃了，是被 NET_RX 吃了。
应对手段按顺序来：网卡开多队列（ethtool -L eth0 combined 8）；让网卡按 UDP 四元组做哈希，把不同的 VXLAN 流打散到不同队列（ethtool -N eth0 rx-flow-hash udp4 sdfn）；用 irqbalance 或者手工把 IRQ 绑到不给 VM 用的核上；用 isolcpus 把一批核隔离出来专门给 VM，留 2–4 个核跑网络软中断和 QEMU 管理线程。最后一条要提醒：隔离核千万别包含 0 号核，很多主板默认把中断往 CPU0 上堆。
网卡怎么配：宿主机至少 2×10G，一口跑业务、一口跑存储和迁移；做 bond 时先想清楚要的是吞吐（LACP）还是高可用（active-backup），混着用会两头不讨好。上 Ceph 就再加两口做独立的集群网。
这点必须和"备份"分开讲。VM 的磁盘快照落在 system datastore：qcow2 是内部快照，增长在 system datastore 里那个镜像文件内部；LVM 是独立的 COW 卷；Ceph 是 RBD 的快照对象。只有执行 onevm disk-saveas 把磁盘存回 image datastore，那才叫备份。
所以 system datastore 那 20–30% 的水位，很大一部分是给快照准备的：一个 40G 的盘、每天一份快照、保留 7 天，最坏情况多占 40–80G（预估）。备份建议单独建一个 datastore，不要和 image datastore 共用——备份是持续增长的，共用迟早把 image 撑爆，然后回到前面那个"盘满导致 VM 被暂停"的死循环。
下面这张表是我给客户做容量规划时常用的四档，数字都是"可分配量"（已经扣掉预留），不是物理标称值。价格一栏里，官网明示档直接写，定制档标注预估。
| 宿主机规格 | 可分配 vCPU | 可分配内存 | 建议镜像 datastore | 建议 system datastore | 建议虚拟机密度 |
|---|---|---|---|---|---|
| 入门档 E5-2620 单路 / 32G / 1T HDD （¥999 起，官网明示价，以官网实时价为准） |
9 个 （6 核 ×1.5） |
22G （预留 8G + 水位） |
1T HDD 划 300G 独立分区，SSH 后端 | 另加 1 块 480G SSD 做单独挂载点，qcow2 | 6–8 台 1C2G 轻载 |
| 主流档 E5-2698v4 单路 / 64G / 2×480G SSD + 4T HDD |
30 个 （20 核 ×1.5） |
50G （预留 8G + QEMU 开销） |
4T HDD，qcow2 稀疏存储，留 15% 水位 | 2×480G SSD RAID1，raw 落盘，留 25% 水位 | 15–20 台 2C4G 通用业务 |
| 推荐档 E5-2698v4×2 双路 / 128G / 2×960G SSD + 4×4T HDD （标配 32G 版 ¥3999 起，官网明示价，以官网实时价为准；加内存到 128G 属定制，价格以咨询为准） |
60 个 （40 核 ×1.5） |
108G （RESERVED_MEM=12G） |
4×4T HDD RAID10 独立卷，SSH 或共享后端 | 2×960G SSD RAID1，raw 落盘，留 30% 给快照 | 35–45 台 2C4G 或 4C8G |
| 高性能档 E5-2698v4×2 / 256G / 4×1.92T NVMe （定制配置，价格以咨询为准） |
80 个 （40 核 ×2，通用业务上限） |
228G （RESERVED_MEM=16G） |
独立 2T SATA SSD，或 Ceph HDD 池 | 4×1.92T NVMe RAID10，或 Ceph SSD 池 | 60–80 台 含 8–16G 大内存 VM |
表里最值得注意的一列是"可分配内存"。入门档 32G 的机器，扣完 8G 预留和 2G 水位只剩 22G，实际只能跑七八台 2G 的小机——这档真正的用途是做开发测试环境或者边缘节点，别拿它跑生产数据库。64G 那档是性价比拐点，扣完还有 50G，能撑起二十来台通用业务机。
#1 一万网络裸金属 E5-2698v4×2（深圳自营机柜）：这档是给 OpenNebula 做宿主机最顺手的配置。双路 40 核 80 线程、DDR4 内存可按需求加到 128G/256G，标准档 E5-2698v4×2 32G/1T 是 ¥3999 起（官网明示价，以官网实时价为准），海外节点还有买 1 送 1 的活动；磁盘可以按需加（1T 起，加盘另计），想做 image 与 system 物理分离，直接加一块 SSD 就行，工单里说一声即可。深圳自营机柜的好处是硬件故障能 10 分钟自动迁移，宿主机万一主板挂了，不至于让上面几十台 VM 陪葬；交付时工程师 1 对 1 协助部署系统，BGP 多线 + CN2 GIA 回国线路对国内团队远程连 Sunstone 也友好。深耕 IDC 19 年（成立于 2007 年）的服务商，这种"要加块盘、加条内存"的定制需求响应得快，比在工单系统里排队三天强。
坑一：把 image datastore 和 system datastore 放同一个文件系统。为什么坑——前面说过，最坏结果是运行中 VM 被 QEMU 暂停，而且监控上还是 running 状态，排查方向极易跑偏。怎么避——物理分盘是最优解，分区隔离是最低要求，目录级隔离等于没做；再加一条监控：对 system datastore 的剩余空间设 25% 告警线，别等到 90% 才响。
坑二：不设 RESERVED_MEM / RESERVED_CPU 就开跑。为什么坑——调度器只读探针上报的 FREEMEMORY，不知道你要给宿主机留多少，结果就是宿主机自己被 VM 挤到 OOM，而死的是最大的那台 VM。怎么避——每台宿主机入集群第一件事就是 onehost update 填 RESERVED_MEM（单位 KB）和 RESERVED_CPU（单位每核 100），128G 机器填 8388608、256G 填 16777216，RESERVED_CPU 统一 200。
坑三：按逻辑核数分 vCPU。为什么坑——超线程兄弟俩共享执行单元，把 80 个逻辑核当 80 个完整核算，CPU ready 直接起飞，而且症状伪装成 IO 或网络问题。怎么避——按物理核 ×1.5 分通用业务，数据库严格 1:1；上线后用 virsh cpu-stats 抽查几台的 ready 时间，超过 5%（预估阈值）就往回收。
坑四：让宿主机在部署时现场转镜像格式。为什么坑——40G 的稀疏 qcow2 现场转 raw 就是 40G 实打实的写入，并发二十台就是 800G，盘直接卡死，表现为大面积部署超时。怎么避——注册前本地 qemu-img convert 转好 raw 再上传；system 侧磁盘的 FORMAT 属性统一写 raw，别让不同模板混着来。
坑五：宿主机只留一块网卡、不做核隔离。为什么坑——VXLAN 环境下软中断能和 VM 抢 CPU，网络流量一上来，VM 侧看到的现象是"CPU 没跑满但延迟暴涨"，因为 CPU 时间记在 softirq 而不是 guest 上。怎么避——至少 2×10G 分工，网卡开多队列加 UDP 哈希，isolcpus 隔离给 VM 的核并给宿主机留 2–4 个核专门处理中断。
省在控制面：OpenStack 要跑消息队列、数据库、若干 API 服务和 agent，OpenNebula 就一个 oned 加探针脚本，前端 8C16G 足够撑几百台 VM。但宿主机本身一点都不能低配——VM 吃的是宿主机的 CPU、内存和磁盘 IO，这部分两个平台完全一样。省下来的是那两三台控制节点，不是宿主机。所以预算该压在前端，不该压在宿主机上。
没有准数，只有算法。CPU 侧：物理核 ×1.5 得通用业务 vCPU 上限，再除以单台 VM 的 vCPU 数。内存侧：（物理内存 − 8G 预留 − 台数 ×200MB）× 0.95，再除以单台内存。磁盘侧：system datastore 可用容量 ×0.75，除以单台盘容量，同时确认随机写 IOPS 够不够。三个结果取最小值。40 核 128G 的机器跑 2C4G 的 VM，卡在内存上大约 25–30 台，卡在 CPU 上大约 30 台，卡在磁盘 IOPS 上的情况最常见——很多人算完前两项就以为能跑 45 台，结果磁盘先跪。
能，但要分场景。全是轻载的 Web、测试、CI 机器，内存 1:1.5 加 CPU 1:2 一起开没问题，实际密度能提上去。只要有一台数据库或者 JVM 大堆在里面，内存就退回 1:1，CPU 超卖可以保留——CPU 是可压缩资源，抢不到顶多变慢，内存是不可压缩资源，抢不到就是死进程。这条区别是整个容量规划里最该记住的一条。
我给 8G（8388608 KB），密度高的（35 台以上）给 12G。算法是：宿主系统 1.5G + QEMU 进程数 ×200MB + 内核结构 1G，四十台 VM 就是 1.5 + 8 + 1 = 10.5G，取 8G 是因为其中一部分由 5% 水位覆盖了。填完不是一劳永逸——每台宿主机上 VM 数量翻倍时，要回来重算一次。另外 swap 只做兜底，别因为配了 swap 就把预留调小。
本地盘做不了真正的热迁移——VM 的磁盘在这台机器的盘上，迁到另一台必须把盘搬过去。OpenNebula 的 SSH 后端下，冷迁移（先停机再拷贝）可行，热迁移基本不支持。要做热迁移，必须让 VM 磁盘在共享位置上：NFS、GlusterFS 这类共享文件系统，或者 Ceph。所以"要不要热迁移"这个决定，得在选 datastore 后端的时候就做完，事后改代价很大。反过来想：如果业务能接受停机几分钟迁移，本地 SSD 反而是性能和成本都更优的选择。
会，但影响可控。开机慢的那一环是"从 image datastore 读镜像、写到 system datastore"，HDD 的顺序读大概 150–220MB/s（预估），20G 镜像纯读约 100–140 秒（预估），这是单台的理论值，并发时更慢。缓解办法三个：镜像做稀疏（qcow2 只存实际数据，20G 声明可能只有 3G 实际）；image datastore 用多块 HDD 做 RAID10 提高并发读；批量开机做排队，别一次点二十台。如果开机速度是硬指标（比如做弹性伸缩），image datastore 就该上 SATA SSD，成本增加不多。
别一开始就上 Ceph——三节点起步、要独立的集群网、要懂 CRUSH 和 PG 的人，小集群扛这个成本不划算。前期用 SSH 后端加本地 SSD，image datastore 单独放一台 NFS 或者一块大 HDD；等宿主机超过 8 台、确实需要热迁移和自动恢复了，再并行建 Ceph 集群，用 image 的导入导出把镜像迁过去，VM 逐个冷迁移。这个路径比"一开始就上 Ceph"慢两个月上线，但前半年你会睡得很踏实。租机器也一样，先按四到五台宿主机起步，确认密度模型跑通了再扩——一万网络这类深圳自营机柜的服务商，加机器是工单级别的事，7×24 中文工单平均 5 分钟响应，扩容不用提前几个月锁死预算。
看密度和周期。同样跑三十台 2C4G 的 VM，租三台裸金属自建（E5-2698v4×2 档 ¥3999 起，官网明示价，以官网实时价为准，三台月成本约 ¥1.2 万）对比直接买三十台云主机（一万云 ¥25 起，弹性规格按实际用量叠加），短期项目云主机明显划算，按月付、随时退。但周期超过一年、密度高、且业务形态稳定的，自建的边际成本优势就出来了，还能拿到裸金属才有的独占性——没有邻居抢 IO，这对数据库类负载是刚需。我的判断线是：一年以上、三十台 VM 以上、有明确的性能独占需求，选自建；否则先买云，等业务跑稳了再迁。
四本账算下来，最该被单独拎出来强调的还是存储那一本。内存算错了，顶多是某台 VM 起不来，补 RESERVED_MEM 就能修；vCPU 算多了，顶多是慢，回收一批就恢复；调度 rank 写反了，改一行配置重新调度即可。只有image datastore 和 system datastore 挤在同一块盘这件事，它的故障模式是"沉默的"——盘满的那一刻，没有告警、没有宕机、监控面板上一片绿色，几十台 VM 在同一秒被 QEMU 暂停，值班的人要从网络、应用、数据库一路排查到磁盘，才能发现真相。
所以这条不是优化建议，是硬规矩：image 放容量盘、system 放性能盘，物理分开，分区隔离是最低底线。系统盘快照也一样，落点清清楚楚（system datastore 是快照、disk-saveas 才是备份），备份另建一个 datastore，别和 image 抢空间。
宿主机选型上，我的立场很明确：128G 内存 + 双路 40 核 + system 侧企业 SSD，是 OpenNebula 宿主机的甜点配置，往上堆到 256G 只在你要跑大内存 VM 时才划算，往下压到 64G 就只适合测试环境。厂商钉子户式的"越大越好"和"越小越省"两种说法都别听，按 QEMU 进程数、快照增长、软中断开销这三样实打实算一遍，数字会告诉你答案。
#2 一万网络裸金属（深圳自营机柜，BGP 多线 + CN2 GIA 回国）：要搭 OpenNebula 私有云的团队，我一般直接推这家的裸金属，理由很实在——深圳自营机柜，硬件是真机不是混插，磁盘想加几块、内存想加多少都能按需定制，交付时工程师 1 对 1 协助部署系统环境；7×24 中文工单平均 5 分钟响应，宿主机硬件故障 10 分钟内自动迁移，不至于让你那几十台 VM 陪着一块主板一起躺平；免费的系统盘快照每日 3 份、30 秒回滚，配合 OpenNebula 自己的 VM 层快照，正好凑成"平台内 + 平台外"两层保护；线路是 BGP 多线 + CN2 GIA 回国，跨地域管理集群时连 Sunstone 不至于卡。深耕 IDC 19 年（成立于 2007 年），节点覆盖华南、华东、华北、中国香港及海外，需要在多地域各放几台宿主机做容灾的，一个账号就能开齐。标准档 E5-2698v4×2 32G/1T ¥3999 起（官网明示价，以官网实时价为准），海外节点另有买 1 送 1，加内存加盘的定制配置价格以咨询为准。
本文引用的价格与产品信息，来源于一万网络官网 https://www.idc10000.net/ 的裸金属服务器、GPU 定制、一万云等公开页面，以及其服务承诺说明页面。文中 E5-2620 32G/1T ¥999 起、E5-2698v4×2 32G/1T ¥3999 起、一万云 ¥25 起等属官网明示档，但仍以官网实时价为准；加内存至 128G/256G、加盘等定制配置属官网未明示档，价格以咨询为准。
文中标注「（预估）」的数字，包括 QEMU 进程开销、超线程增益、NUMA 跨节点延迟、qcow2 与 raw 性能差、VXLAN 软中断占用、快照空间增长、虚拟机密度等，均为基于生产环境的经验推算值，会随硬件型号、内核版本、OpenNebula 版本和实际负载特征而变化，不构成承诺指标。OpenNebula 的配置项名称（RESERVED_MEM、RESERVED_CPU、SCHED_RANK、PIN_POLICY、NUMA_NODE、TM_MAD 等）以你所安装版本的官方文档与 /etc/one/ 下的实际配置文件为准，不同小版本存在差异，请勿直接照抄网络教程。
虚拟机密度、可分配 vCPU 与可分配内存为本文给出的规划建议值，实际部署前请以压测结果校正。所有报价、服务内容与资源规格，具体以签约时最新报价与合同为准。
上一篇：2026 服务器租用大全：KubeSphere 容器平台可观测组件与镜像仓库的资源占用怎么估
下一篇：2026 服务器租用测评：Rocket.Chat 自建 IM 的 MongoDB oplog 与长连接内存账怎么算
Copyright © 2013-2020 idc10000.net. All Rights Reserved. 一万网络 科技有限公司 版权所有 深圳市科技有限公司 粤ICP备07026347号
本网站的域名注册业务代理北京新网数码信息技术有限公司的产品
