Exercise 3: Why Steal Time Can't Be Fixed From Inside the VM — Possible Solution
====================================================================

WHAT STEAL TIME MEASURES
------------------------------
Per this chapter, st ("steal time") is "on a virtual machine, time this
VM wanted to run but the hypervisor gave the physical CPU to a
different tenant instead." It represents CPU time this virtual machine
was ready to use but didn't get, because the underlying physical
hardware gave that time to a different virtual machine sharing the
same host.

WHY IT'S NOT FIXABLE FROM INSIDE THE AFFECTED VM
------------------------------
Per this chapter's warn-box, "a nonzero st figure means the physical
hardware underneath this machine is genuinely oversubscribed by the
hosting provider - no amount of tuning inside this particular system
will fix it, because the CPU time is being taken away one layer below
where this system has any control." The decision about which VM gets
physical CPU time is made by the hypervisor, a layer entirely outside
what any process or configuration change running inside this specific
VM can influence.

WHY RECOGNIZING THIS EARLY MATTERS
------------------------------
Per this chapter, "recognizing steal time early avoids a long,
fruitless search through this machine's own processes for a cause
that isn't there." Without checking st specifically, an engineer could
spend significant time investigating this VM's own processes for a
CPU bottleneck that doesn't actually originate inside the VM at all.

WHY THIS WORKS AS AN ANSWER
------------------------------
It defines steal time accurately as hypervisor-level CPU contention,
explains specifically why that places the cause outside the VM's own
control (a layer below where the VM's own configuration operates), and
connects this to the chapter's own stated benefit of recognizing it
early rather than just saying "it's outside your control" without
explaining the layering.