An NCC health check fails for Curator on an upgraded AHV cluster. The admin sees no VM outage but wants to know which Nutanix AOS functions are most directly affected by Curator. Which functions should be investigated first?
Select an answer to reveal the explanation.
Short Explanation
Think of Curator as the janitor that cleans up data after writes land: dedup, compression, and EC-X run there. If an NCC health check flags Curator, you don't chase networking or replication first; you check the data-reduction pipeline. That's where the failed check points you.
Full Explanation
Curator is the AOS background data-services engine that performs post-process reduction and placement work, including deduplication, compression, and EC-X, after data has been written. Because those jobs are asynchronous and can be resource-sensitive, an upgrade can expose Curator health failures even when VMs continue to run normally. Metadata lookup and placement operations handled by Stargate and Cassandra are wrong because those components serve the I/O path metadata and distributed consensus functions, not Curator's post-write data services. Replication scheduling and snapshot lifecycle managed by protection domains are wrong because protection domains coordinate replication and snapshots across clusters, not local data-reduction processing. Hypervisor network bridge and bond configuration used by AHV for VM traffic is wrong because networking components affect packet forwarding and link redundancy, not Curator health checks. Exam caveat: a Curator alert should lead you to data services and capacity efficiency, not to protection policy or network troubleshooting. Operational check: review NCC output and Prism alerts for Curator-related data services, then confirm dedup, compression, and EC-X job status before escalating.