Per-vCPU steal sampling catches the unstable vCPU an aggregate average hides

A runnable vCPU in a KVM guest still needs a host CPU thread before it executes anything. Linux books the time the guest wanted to run while the hypervisor ran something else as %steal ^[6]. An aggregate CPU line can hide one unstable vCPU, so the method saves per-vCPU %usr, %sys, %iowait and %steal, with vmstat adding runnable tasks, blocked tasks and context switches ^[7]. The article says, "Steal time is evidence, not a verdict," and asks for coincidence instead: did throughput fall in the same seconds steal rose, and does the pattern repeat across runs or at different times of day ^[8][9]. Low steal still leaves the dedicated-CPU claim unproven ^[10].

%iowait is not disk latency. It is CPU accounting time during which a CPU sat idle while I/O was outstanding, so a guest can have slow storage and very little iowait when other runnable work keeps the CPU busy ^[11]. Storage latency has to be measured from the I/O request and observed at the block layer ^[12]. The text available ends mid-sentence inside the CPU procedure, before any storage command appears ^[13].

The CPU half splits in two because a multi-threaded score mixes how fast one vCPU executes with how well the scheduler runs several of them at once ^[14]. The procedure warms the code path with a 20-second run discarded to /dev/null, then takes a 60-second timed run of one sysbench worker at --cpu-max-prime=20000 under taskset -c 0 ^[15]. taskset removes one source of variation, movement between guest vCPUs. The article states plainly that it does not pin the work to a physical Ryzen core, because only the hypervisor operator can make that guarantee ^[16].

That evidence takes time to collect. The two baselines as written, mpstat -P ALL 1 60 and vmstat 1 60, each take 60 one-second samples ^[17]. Add the 20-second warm-up and the 60-second timed run and a single pass runs to 200 seconds of measurement before storage is touched ^[1].

The author writes that this is not a ranking system and produces no universal performance number ^[18]. For a sysbench result to mean anything on a second host, the build and the prime limit have to match, since scores from different builds or prime limits are not directly comparable ^[19]. The plan's vCPU count, memory and storage allocation belong in the record as test inputs ^[20]. The decision the result must support gets written down before the tool is installed, because a web worker, a compilation runner and a nightly database report stress different parts of a system ^[21].

On a production guest the method calls for explicit load and latency stop conditions ^[22]. The article gives the reason in one line: "A benchmark that harms the workload it is meant to evaluate has failed operationally even if its data is technically valid." ^[23]