CPU steal 高却找不到 vmware-tools 进程，是因为缺少 open-vm-tools 导致 guest 无法与 hypervisor 协同调度，vCPU 时间片分配失控；需安装并启用 open-vm-tools、vmtoolsd、vmware-kmod（RHEL/CentOS）三服务，同时禁用 ESXi 的 CPU limit 和 CPU Hot Add 干扰项。
为什么 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”。
CentOS Linux 7.9.2009是传统CentOS Linux 7的最后主要版本，也是很多企业历史服务器中仍可能遇到的系统版本。它以稳定、兼容RHEL 7生态、文档丰富和软件支持广泛著称，曾长期用于Web服务、数据库、虚拟化节点和企业内部业务系统。不过CentOS Linux 7已于2024年6月30日停止维护，现在继续使用会面临安全补丁缺失风险。该版本更适合旧业务迁移、历史环境恢复或离
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 版本改善调度公平性。
