You are performing a rolling upgrade of AOS and AHV on a four-node Nutanix cluster hosting production VMs. The cluster is healthy, and you have confirmed sufficient redundancy for a rolling reboot. During the upgrade, what is the expected behavior for the running virtual machines?
Select an answer to reveal the explanation.
Short Explanation
Think of a rolling upgrade like changing a tire on a moving car—you don't stop the car, you just swap one tire at a time. Nutanix uses live migration to move VMs off a node before it reboots for the update. If you see VMs powering off or getting HA-triggered restarts, something went wrong with the migration, not the upgrade design itself.
Full Explanation
A rolling upgrade works by draining each node before it reboots. If migration cannot complete, LCM should hold or fail the precheck rather than forcing a disruptive reboot. LCM coordinates with AHV so live migration moves running VMs to other healthy nodes, then the upgraded node rejoins the cluster. This preserves service continuity and uses the cluster's existing redundancy rather than interrupting guest workloads. Suspending VMs is not the normal rolling-upgrade behavior; it introduces a pause and is used only when migration is deliberately not desired. Powering VMs off is also wrong because a controlled rolling upgrade should not stop workloads as its intended path. Waiting for HA to restart VMs is a failure response, not the design; HA reacts to unexpected host loss, while live migration is the planned mechanism that avoids downtime. Exam caveat: Live migration requires sufficient spare capacity and compatible VM placement rules, so pre-checks matter. Operational check: Confirm LCM prechecks, verify no host-pinned or anti-affinity constraints block migration, and monitor migration status before the reboot phase.