A business-critical database VM on AHV starts showing disk latency during nightly batch jobs, while other VMs on the same Nutanix cluster are generating heavy storage load. You need to protect the database's storage performance without capping the database itself. Which control should you configure in Prism Central?

Nutanix storage QoS is configured through Prism Central storage policies, which are associated with VMs through categories. The QoS setting is a throttle: it sets a maximum IOPS or throughput for the VMs the policy covers. There is no IOPS floor or per-disk I/O reservation, so protecting a critical workload means limiting the workloads that create contention. Placing the batch VMs in a category tied to a throttling storage policy caps how much load they can push during the nightly window, which frees controller and disk resources for the database and lowers its latency. Putting a QoS cap on the database's own disk is backwards: it limits the very workload you are trying to protect and does nothing to restrain the noisy neighbors. A VM affinity rule controls which hosts a VM runs on; storage is distributed across the cluster, so placement alone does not reduce storage contention. Memory settings do not address disk latency caused by other VMs' I/O. Exam caveat: storage policies in Prism Central cover encryption, compression, QoS throttling and replication factor, and QoS is throttle-only. Operational check: after associating the policy, compare the database VM's read and write latency and the batch VMs' IOPS in Prism during the next batch window.