CPUsteal高未装VMwareTools解决方案

当虚拟机中CPU steal时间持续偏高却找不到vmware-tools进程或相关服务运行迹象，根源往往在于缺失open-vm-tools及其配套内核模块，导致客户机无法与ESXi超管理器协同调度，vCPU时间片分配失控；正确安装并启用open-vm-tools、vmtoolsd和（RHEL/CentOS专属）vmware-kmod三项服务，同时在ESXi端关闭CPU limit和CPU Hot Add等干扰策略，才能从根本上缓解steal虚高问题——这不仅是工具安装，更是打通虚拟化调度闭环的关键一步。

为什么 CPU steal 高却找不到 vmware-tools 进程

CPU steal 时间高，说明 guest OS 的就绪任务被 hypervisor 暂停等待 CPU 资源，但 vmstat 或 top 里看不到明显瓶颈进程——这往往是因为缺少 vmware-tools（或现代等价的 open-vm-tools）。没有它，guest 内核无法通过 VMCI 或 hypercall 与 ESXi 协同调度，vCPU 时间片分配完全依赖默认的 CFS 调度器 + 虚拟化层盲等，导致 steal 时间虚高且不可控。

常见现象包括：steal% 持续 >10%，但 %us/%sy 很低；ps aux --sort=-pcpu 找不到高 CPU 进程；cat /proc/sched_debug 显示大量任务在 rq->nr_uninterruptible 中滞留。

• CentOS/RHEL 7+ 默认不预装 open-vm-tools，需手动安装
• Ubuntu 18.04+ 虽预装，但若被 apt remove 清理过，systemctl is-active open-vm-tools 会返回 inactive
• vmware-toolbox-cmd -v 或 vmtoolsd --version 直接报 “command not found” 是最简判断依据

open-vm-tools 安装后必须启用的三个服务

只装包不启服务，steal 不会下降。关键不是 vmtoolsd 进程本身，而是它注册的内核模块和定时同步机制。

• systemctl enable --now open-vm-tools：启动主守护进程，提供时间同步、剪贴板、分辨率适配等功能
• systemctl enable --now vmtoolsd（部分发行版别名）：确保 /usr/bin/vmtoolsd 加载 vmmemctl 模块，参与内存 ballooning 和 vCPU 抢占通知
• systemctl enable --now vmware-kmod（仅 RHEL/CentOS 7）：加载 vmwgfx、vmmemctl 等内核模块，否则即使进程在运行，/proc/vmware 下也无节点，hypervisor 无法回调

验证是否生效：lsmod | grep -E 'vmw|vmmem' 应有输出；cat /proc/vmware/version 不报错；vmware-toolbox-cmd stat balloon 返回实际 ballooning 值而非 “not supported”。

ESXi 层需关闭的两个默认干扰项

即使 guest 侧装好 open-vm-tools，若 ESXi 上启用了某些资源限制策略，steal 仍可能居高不下，因为这些策略绕过了 tools 的协同逻辑。

• 禁用 CPU limit（MHz）：在 VM 设置 → Resources → CPU → Limit 中设为 Unlimited。设了硬限制后，ESXi 会在 vCPU 就绪队列满时直接丢弃时间片，steal 计数飙升，且 guest 无法感知
• 关闭 CPU Hot Add：VM 设置 → Options → General → Configuration Parameters → 编辑配置 → 添加 cpuhotadd.enable = "FALSE"。该功能开启时，vCPU 动态增减会触发内核重调度锁，造成短暂但高频的 steal 尖峰

注意：CPU Shares 和 Reservation 可保留，它们通过调度权重和预留保障参与协同，不干扰 open-vm-tools 的反馈回路。

steal 高但 tools 已运行时的排查路径

如果确认 open-vm-tools 正常运行、ESXi 设置也合规，steal 仍异常高，问题大概率不在工具链本身，而是资源争抢模式发生了变化。

• 检查 esxtop 在 ESXi Shell 中的 PCPU USED%：若单个物理 CPU 核心持续 >95%，说明宿主机过载，guest 被强制节流，steal 是真实反映，此时应横向扩容或迁移 VM
• 运行 vmware-toolbox-cmd stat cpu：输出中 ready 时间占比 >20% 表示 vCPU 就绪队列积压，需检查同主机其他 VM 的 CPU 使用模式
• 对比 cat /sys/devices/system/clocksource/clocksource0/current_clocksource：若为 jiffies 而非 tsc 或 vmware_pit，说明时钟源未切换，会导致 CFS 调度周期计算失准，steal 统计偏高（需加内核参数 clocksource=vmware_pit 并重启）

真正难处理的是混合场景：宿主机 CPU 利用率中等（60–70%），但某几个 PCPU 核心打满，同时 guest 内 open-vm-tools 正常、clocksource 正确——这时 steal 高是调度器局部饱和的真实体现，没有一键修复，只能靠调整 VM 分布或升级 ESXi 版本改善调度公平性。

到这里，我们也就讲完了《CPUsteal高未装VMwareTools解决方案》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！