After a disk failure, EC-X rebuild begins. Prism performance shows VM disk latency rise, lower IOPS, and no CPU or memory anomalies on CVMs or VMs. Which performance factor should you investigate first?
Select an answer to reveal the explanation.
Short Explanation
Think of a disk rebuild like moving furniture while people are trying to use the room: the traffic is real, and it can slow everyone down. You should look at EC-X rebuild I/O first, not at Flow or Prism alerting. The latency jump lines up with resiliency work, not with a policy or memory eviction.
Full Explanation
When a disk fails, Nutanix resiliency processes begin rebuilding or reprotecting affected data. EC-X rebuild activity moves data across remaining disks and nodes, consuming bandwidth, IOPS, and CPU on CVMs while the cluster restores redundancy. That background I/O can raise VM disk latency and reduce available IOPS even when no VM workload change occurred, so the correct factor is storage resiliency traffic competing for I/O. Prism Central alerting does not normally throttle VM disk I/O as a response to latency alerts; it reports and correlates conditions rather than applying data-path rate limits. Flow policies affect network inspection and routing, not disk latency directly, and they would not be triggered by a failed physical disk. Working-set eviction can cause cold reads, but it is not the first cause when a disk failure has just started a rebuild and no memory-pressure evidence is shown. Exam caveat: do not confuse a resiliency performance impact with a misconfigured storage policy; rebuild traffic is expected and should be correlated with health events. Operational check: review the disk failure and EC-X rebuild status in Prism, then compare latency and IOPS trends before and after rebuild completion.