虚拟化宿主机资源配额核心是按业务角色分层控制：关键服务保预留、非关键服务设限制、所有服务配份额；需结合cgroups/virtio、kvm/esxi及负载特征落地，通过预留（保障下限）、限制（硬性封顶）、份额（争抢时权重）三参数差异化配置，并动态验证微调。
为虚拟化宿主机规划资源配额，核心不是“平均分配”，而是按业务角色分层控制：关键服务保下限、非关键服务设上限、所有服务有优先级权重。这需要结合内核机制（cgroups/virtio）、平台能力（KVM/ESXi）和实际负载特征来落地。
明确三类资源参数的实际作用
无论用 KVM、ESXi 还是 Proxmox，资源调度都依赖三个基础参数，但含义常被混淆：
- 预留（Reservation）：保证最低可用资源，比如数据库虚拟机必须始终拿到 4 核 CPU 和 8GB 内存，哪怕宿主机整体紧张；
- 限制（Limit）：硬性封顶，防止单个虚拟机吃光资源，例如测试机最多用 2 核 CPU，超了就 throttle；
- 份额（Shares）：仅在资源争抢时生效的相对权重，不争抢时不起作用——Web 服务设 2048，后台任务设 512，意味着前者能拿到约 4 倍于后者的空闲 CPU 时间。
按业务类型差异化配额
同一台宿主机上混跑不同负载时，配额必须体现业务等级：
- 核心服务（如 MySQL、Redis、主站 API）：预留 ≥ 60% 预估峰值需求，限制设为物理资源的 80%，份额设最高（KVM 推荐 2048，VMware 推荐 2000）；
- 普通服务（如 Nginx、Node.js 前端）：预留 30%～40% 峰值，限制与预留一致或略高，份额设默认值（1024 / 1000）；
- 临时/测试类虚拟机：不设预留，限制严格（如 CPU ≤2 核、内存 ≤4GB），份额设最低（512 或更低），避免干扰生产。
磁盘与 I/O 配额不能只看容量
SSD 宿主机常见陷阱：空间还有 30%，但 I/O 延迟飙升、响应变慢——这是因为没管好 I/O 权重和 inode：
- 用
virsh blkiotune（KVM）或esxtop（ESXi）给数据库 VM 设置更高 I/O 份额，确保它在磁盘争抢时优先获得队列时间； - 对 Web 服务器的
/var/log和/tmp目录启用 quota，单独限制 inode 数量（edquota -i username），防止日志轮转或上传缓存生成海量小文件耗尽 inode； - XFS 文件系统上，直接用
xfs_quota设置项目配额（project quota），比用户配额更适配虚拟机目录隔离场景。
动态验证与微调才是关键
配额不是设完就一劳永逸。上线后需持续观察真实竞争行为：
- 用
cat /sys/fs/cgroup/cpu/<vm-name>/cpu.stat</vm-name>查看 throttled_time，若该值持续增长，说明 CPU 限制太紧； - 运行
docker stats（容器）或virsh domstats（KVM 虚拟机）对比实际使用与配额设定，偏差超 30% 就该调整； - 压力测试时模拟流量高峰，重点看 OOM killer 是否触发、swap 使用是否上升、I/O wait 是否超过 15%，这些信号直接反映配额是否失衡。
