virsh domstats 是唯一能穿透虚拟化层获取 KVM 内核级 CPU 和内存真实指标的命令，返回 cpu.time（纳秒累加）、memory.actual（客户机实际物理页 KB 数）和 balloon.current（气球释放量 KB），不受 QEMU 进程 RSS 或 KSM/气球机制干扰。
直接看 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 格式化更可控：
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
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 合并页的元数据）。它完全不反映客户机内部真实负载。
- 启用内存气球后，
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 调度器和内存管理的耦合逻辑里，容易被脚本输出掩盖。
