Linux怎么监控KVM宿主机所有虚拟机实时的物理资源消耗占比-LINUX-PHP中文网

virsh domstats 是唯一能穿透虚拟化层获取 KVM 内核级 CPU 和内存真实指标的命令，返回 cpu.time（纳秒累加）、memory.actual（客户机实际物理页 KB 数）和 balloon.current（气球释放量 KB），不受 QEMU 进程 RSS 或 KSM/气球机制干扰。

linux怎么监控kvm宿主机所有虚拟机实时的物理资源消耗占比

直接看 virsh 提供的原生指标最可靠，ps 或 top 显示的 RES/%MEM 会严重失真——尤其启用了内存气球（balloon）或 KSM 合并页时，宿主机看到的“物理内存占用”和虚拟机实际使用的内存根本不是一回事。

用 virsh domstats 查每个 VM 的真实 CPU 和内存使用率

virsh domstats 是唯一能穿透虚拟化层、拿到 hypervisor 级别统计的命令，它返回的是 KVM 内核模块直接采集的数据，不受用户态 QEMU 进程 RSS 干扰。

CPU 使用率来自 cpu.time（纳秒级累计时间），除以采样间隔和 vCPU 数，算出百分比，比 ps 的 %CPU 更准
内存关键字段是 balloon.current（当前气球大小）、memory.actual（客户机实际分配到的物理页数），而非 ps 的 RES
执行 virsh domstats --current --blocked 可一次性获取所有运行中虚拟机的快照，加 --no-header 便于脚本解析

写个每秒刷新的实时监控脚本（不依赖 htop/top）

别用 watch virsh domstats，输出太碎。直接用 shell 循环 + awk 格式化更可控：

while true; do
  echo "=== $(date +%H:%M:%S) ==="
  virsh list --state-running --name 2>/dev/null | \
    while read vm; do
      stats=$(virsh domstats "$vm" 2>/dev/null | \
        awk -F'=' '/^cpu.time|memory.actual|balloon.current/ {gsub(/ /,"",$2); print $2}')
      cpu_time=$(echo "$stats" | head -1)
      mem_actual=$(echo "$stats" | sed -n '2p')
      balloon=$(echo "$stats" | sed -n '3p')
      # 计算 CPU%：需先取上一周期值，此处简化为单次差值（生产建议用两次采样）
      echo "$vm: CPU(ns)=$cpu_time MEM(KB)=$mem_actual BALLOON(KB)=$balloon"
    done | column -t
  sleep 1
done

注意：cpu.time 是累加值，要算实时占比必须做两次采样求差；上面脚本只展示原始字段，真要百分比得缓存上一轮值
memory.actual 单位是 KB，balloon.current 是客户机主动释放的内存量，两者相减才是客户机真正“握在手里”的物理内存
如果某 VM 返回空，说明它没在运行，或 libvirt 权限不足（检查是否用 root 或 libvirt 组用户执行）

为什么 ps aux | grep qemu-kvm 的 RES 不可信

ps 显示的是 QEMU 进程自己的内存开销，包括：QEMU 二进制代码、线程栈、设备模拟缓冲区、以及客户机内存的“影子副本”（如 KSM 合并页的元数据）。它完全不反映客户机内部真实负载。

Linux Security Scanner

Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...

下载

启用内存气球后，ps 的 RES 可能比 memory.actual 高 30% 以上——因为气球页被客户机标记为“可用”，但宿主机还没回收
开启 KSM（Kernel Samepage Merging）后，多个 VM 共享相同内存页，ps 会把共享页重复计入每个 QEMU 进程的 RES，导致总和远超物理内存总量
ps 看不到 vCPU 调度延迟、I/O 等待这些 KVM 层瓶颈信号，纯属用户态视角盲区

补充：识别真正的性能瓶颈不能只盯数字

即使 virsh domstats 显示 CPU% 和 memory.actual 都正常，业务仍卡顿？立刻查底层信号：

运行 perf kvm stat live，重点看 PAUSE_INSTRUCTION 占比——超过 5% 就说明 vCPU 被频繁抢占，得调 vCPU 绑定或减少 overcommit
执行 numastat -c qemu-kvm，确认各 VM 内存是否都落在同一 NUMA 节点；跨节点访问会让延迟翻倍
在宿主机跑 vmstat 1，盯着 r（就绪队列）、cs（上下文切换）、wa（I/O 等待）三列：r > 物理核数、cs > 50000、wa > 20%，分别指向调度、中断、存储瓶颈

真正难的不是采集数据，而是理解 memory.actual 和 balloon.current 的差值意味着什么，以及为什么 PAUSE_INSTRUCTION 高了就得动 vCPU 绑定策略——这些细节藏在 KVM 调度器和内存管理的耦合逻辑里，容易被脚本输出掩盖。