A production VM on AHV shows high CPU ready and its host is CPU-saturated. Prism shows other cluster nodes have spare CPU. You need reduce contention with minimal disruption. What should you do?
Select an answer to reveal the explanation.
Short Explanation
Think of it like a crowded elevator: don't reprogram the buttons, just move the passenger. You live-migrate the VM off the hot host so its workload lands where CPU is free. Reservations and affinity rules help policy, not an already-saturated box.
Full Explanation
Live migration is the direct remediation when one AHV host is CPU-saturated but the cluster has spare capacity. It moves the running VM state to a less loaded host, lowering CPU ready and host contention without a guest reboot. Prism shows which host is hot and which nodes have spare CPU, so the administrator can choose a target that avoids overloading another node. Reservations change the VM scheduling expectation, not the physical load on the current host, so they do not relieve a hot node and can increase scheduling pressure. Anti-affinity is an availability placement rule that keeps VMs apart; it is not an immediate rebalancing action and does not move an already loaded VM off a saturated host. Adding nodes expands cluster capacity, but it is a capacity-planning step, not the quickest way to fix one VM causing contention. Exam caveat: if the stem says other hosts have spare capacity and the goal is minimal disruption, choose migration or rebalancing rather than configuration or expansion. Operational check: inspect the VM CPU ready and the host CPU utilization in Prism, confirm the target host has headroom, then perform a live migration and re-check the metric.