A VM That Cannot Migrate During Maintenance Mode
A six-node AHV cluster is scheduled for an AOS upgrade. Node C hosts two unusual VMs. VM AI-Train-01 has 32 vCPU, 256 GB RAM, and two physical GPUs attached as PCI passthrough devices. VM Billing-01 has a host affinity policy that pins it to node C because of a legacy licensing constraint on that host. The operator enters node C into maintenance mode and selects the migrate-all-VMs option. AI-Train-01 remains on node C and the maintenance task eventually fails; Billing-01 migrates and immediately loses connectivity to its licensing server.
1. Explain the two distinct failures and what each tells you about AHV migration.
Read the worked answer
AI-Train-01 is blocked by PCI passthrough. A VM with a passed-through device has a direct hardware binding to that host; live migration would require moving the device, which AHV cannot do. The maintenance-mode workflow can only live-migrate VMs that are migratable, so it stalls on this VM. The correct handling is planned downtime: shut the VM down cleanly, let maintenance mode proceed, then power it back on after the node returns. There is no configuration flag that makes a passthrough VM live-migratable.
Billing-01 is a policy failure, not a technical one. Its host affinity policy is a placement rule that AHV honors; migrating it off node C violates the rule, and once it lands elsewhere its licensing check fails. Maintenance mode should have been blocked or the policy adjusted before the window.
Both cases argue for reviewing the host's VM inventory for passthrough devices and affinity policies before entering maintenance mode, not after the task fails.
2. Write the pre-check list you would run on each node before the upgrade begins.
Read the worked answer
For every node in the cluster, not just the next one:
- List VMs with PCI devices or GPU passthrough and confirm their owners have approved downtime, with a shutdown plan and a restart order.
- List host affinity policies and identify every VM pinned to a node, then agree whether the policy is removed for the window or the VM is stopped.
- Confirm no VM has an active or in-progress clone, snapshot-based restore, or protection-domain snapshot overlapping the window.
- Confirm the cluster is healthy: no data resiliency alerts, no failed disks, no CVM down, and enough free capacity on the remaining nodes to hold the migrating VMs (including memory, not just storage).
- Confirm AHV and AOS versions are compatible for the upgrade path, and that any VM running Nutanix guest tools is current so IP addresses follow the VM after migration.
A pre-check that only counts VMs and not their dependencies is how the AI-Train-01 stall happens in production.
3. The customer says 'just force it through and fix it later.' How do you respond, and what is the sequencing you propose?
Read the worked answer
Forcing the node out of maintenance mode or powering off passthrough VMs without coordination trades an upgrade delay for an unplanned outage and possible data loss on a training workload that may have multi-hour checkpoints. The upgrade does not need to happen all at once.
Proposed sequencing: upgrade the four unconstrained nodes first, one at a time, verifying cluster health between each. Schedule a separate, announced window for AI-Train-01's host, during which the VM is shut down cleanly, node C is upgraded, and the VM is restarted. Resolve Billing-01 by either removing the affinity policy once the licensing constraint is retired or leaving that VM stopped for the window.
Also flag that the licensing constraint on Billing-01 is a standing cluster risk, not just a maintenance-mode inconvenience: the same policy will block any future failure-driven migration. It deserves a ticket of its own.