vCPU overcommit (the fleet dial)
You just promised more virtual CPUs than the servers physically have. That works because tenants are rarely all busy at once -- quiet boxes lend their idle cores to noisy ones. The Fleet CPU overcommit dial in the Capacity view is how hard you push that bet: 1:1 sells only what you own, 3:1 sells three times as much.
Push it too far and a busy stretch turns ugly: every tenant on an overpacked host fights for the same cores, latency climbs, and the slow service is what people leave over. The fix is never to migrate tenants around -- it's to ease the dial back down (new placements get more room) or add a host, before the next busy hour bites. Lowering the dial never moves anyone already running; it just stops you packing the next tenant in too tight.
Detailed explanation
Overcommit is a per-host placement ceiling: usable vCPU = floor(physical x overcommit_target), minus what's already reserved. Common ratios are 3-4x CPU, ~1x RAM (an OOM kill is brutal and customer-visible), 5:1+ on shared SSD IOPS. Steady-state utilization above ~80% pushes p99 into the hockey-stick region. The dial is advisory-for-placement only: lowering it refuses new placements sooner and shrinks reported headroom, but never migrates, re-packs, or evicts a running VM.
The dial sets how many vCPUs you'll SELL; contention is measured against the physical silicon you actually OWN. A host only slows down when real demand exceeds its physical cores -- so a high ratio that never gets busy costs nothing, and dropping the ratio is the remedy for a contended host, not a cause of contention. Match host categories to the tenant mix (ComputeDense for CPU-bound APIs, MemoryOpt for game/DB boxes) rather than overpacking one balanced SKU.