You must relocate an AHV VM from Cluster-A to Cluster-B to relieve a hot storage pool. The VM should be relocated without rebuilding it from a template. Which workflow should you choose, and what storage impact must you account for?
Select an answer to reveal the explanation.
Short Explanation
Think of moving a VM across clusters like moving a house, not just changing its street sign: the disks have to land on the new cluster. You pick the cross-cluster migration workflow and make sure the destination has enough free space and compatible storage before the copy starts. Skip that check and you can fail mid-move or overload the target pool.
Full Explanation
Cross-cluster VM migration is the intended mechanism for relocating an AHV VM between Nutanix clusters for workload placement. It moves the VM and its virtual disks to the destination cluster, so the operation consumes destination capacity and generates storage I/O while the copy completes. The administrator must confirm the destination cluster has sufficient free space, compatible storage configuration, and enough performance headroom to absorb the migration without harming existing workloads. A same-cluster live storage migration only moves disks among nodes inside one cluster; it does not place the VM on a different cluster and does not solve cross-cluster placement. Async VM disk replication is a data-protection pattern, not an operational placement workflow; it also focuses on snapshot retention rather than ensuring the target cluster can host the VM. Cluster expansion adds capacity to the original cluster and may trigger rebalancing, but it does not relocate the VM itself or guarantee the target cluster has capacity for it. Exam caveat: choose the workflow that matches the stated outcome, cross-cluster placement, not a same-cluster or DR mechanism. Operational check: before starting the move, review destination capacity, storage pool utilization, and replication or performance metrics to confirm the VM can be accommodated.