A latency-sensitive application VM on an AHV cluster occasionally slows when other VMs compete for CPU on the same host. AHV does not offer per-VM CPU reservations, shares or limits. Which approach best reduces CPU contention for this VM without capping its performance?

AHV schedules vCPUs as threads on the host's physical cores and does not expose vSphere-style per-VM CPU reservations, shares or limits. Contention therefore comes from how many vCPUs share a host's cores, and your levers are placement and sizing. A VM-host affinity policy in Prism Central restricts the VM to a chosen set of hosts, so you can keep it where you deliberately hold vCPU oversubscription low and keep other busy workloads away. Right-sizing matters too: an oversized VM has more vCPUs to co-schedule and can wait longer for cores under load, so matching vCPUs to measured demand reduces scheduling delay. AHV's Acropolis Dynamic Scheduling also moves VMs off CPU hotspots automatically, which helps once placement is sensible. A vCPU reservation is not an AHV setting, so it cannot be configured. Raising oversubscription does the opposite of what you need: more vCPUs per core means more contention, and a VM can never use more vCPUs than it's assigned. A vCPU limit is also not an AHV control, and capping the VM would contradict the requirement anyway. Exam caveat: when a stem asks for a vSphere control on AHV, look for the AHV equivalent: affinity policies, ADS, right-sizing and oversubscription ratios. Operational check: compare the VM's CPU ready time and the host's vCPU-to-core ratio in Prism before and after moving it.