Your AHV VM is licensed per physical host and depends on a host-attached device. It must stay on the same node across reboots and live migrations. Which action should you take?
Select an answer to reveal the explanation.
Short Explanation
Think of host affinity like a reserved parking spot: you tell the cluster where this VM belongs, so it keeps coming back there. If you rely on manually picking a host, you're just hoping nobody forgets after a reboot or migration.
Full Explanation
Host affinity creates a placement constraint that binds a virtual machine to one or more specified hosts, allowing the hypervisor scheduler to honor that constraint during power-on, live migration, and HA restarts. This matters when software licensing, hardware passthrough, or device dependencies are tied to a particular physical node; the rule persists as configuration instead of depending on an administrator choosing the right host each time. Using anti-affinity would spread the VM away from other VMs or hosts, which is the opposite of pinning it to a required node. Manually selecting a host is an operational workaround, not a durable policy, and can be missed during reboots, failover, or orchestration. Adding the VM to a protection domain controls replication and recovery behavior, not placement, and host pinning is not a protection-domain setting. Exam caveat: distinguish host affinity from anti-affinity, storage affinity, and placement policies; the requirement is a host-bound VM. Operational check: after applying the rule, reboot or live-migrate the VM and verify it returns to the intended host.