Smart Insights with Advanced AHV Infrastructure Metrics

Introduction

The Nutanix AHV hypervisor has steadily been adding powerful features as a premier Enterprise-grade hypervisor for production workloads on enterprises. Visibility and monitoring of these features is one of the key aspects for infrastructure administrators to manage capacity and understand the state of their infrastructure. At Nutanix, we enable you to derive actionable insights by providing this visibility closer to your infrastructure with the usage monitoring and trend charts we currently provide on the Prism Central management console for Memory, CPU and Storage. 

However, as your AHV ecosystem grows and matures, we recognize that customers and users are looking to optimize their hardware, and would like more granularity and information for reporting and capacity management purposes. Across clusters, customers are looking for answers to questions like "How many more VMs can we effectively run on this host?" or “What is the overcommit ratio of CPU and Memory so-far on this host or cluster?” so they can future-proof workload planning for their users. 

In lieu of more memory-intensive workloads increasing the demand for memory as well as constrained memory availability globally, Memory Overcommit has quietly been one of the highly effective economic features in the Nutanix AHV hypervisor. By letting administrators allocate more virtual RAM to workloads than the host physically owns, it captures idle memory, lifts VM density, and allows you to maximise your hardware costs. The mechanics - guest memory ballooning, and hypervisor-level swap have shipped and matured release after release with AHV. AHV Memory overcommit mechanisms prioritise workloads getting sufficient physical memory so they continue to be performant, as well as use host swap backed by the host’s NVMe (or HDD) devices managed from the CVM, orchestrated by the Acropolis Dynamic Scheduler and AHV Host. 

With NCI 7.6, we launch Enhancements to Infrastructure Metrics on Nutanix AHV, a new suite of over 30 metrics via with purpose-built charts in Prism Central, that give IT administrators a heirarchical view (VM ↔ Host ↔ Cluster) of how memory is being configured, used, reclaimed, swapped across every workload in their estate.

Deep Visibility into Memory Usage

To understand the new metrics, it helps to revisit what the Memory Overcommit feature in AHV actually does under the hood. When you enable overcommit on a VM, AHV uses complementary mechanisms to make total configured VM memory exceed physical host RAM safely:

Enhancements made in this release are targeted for customers to have more insights into Memory Overcommit mechanisms on AHV. Customers will be able to monitor some of these key aspects: 

• Existing metrics revisited for Memory Overcommitted VMs. Memory that had already been reclaimed by the host as ballooned memory will no longer count against memory usage for idle overcommitted VMs and this is now enhanced to show actual usage for overcommitted VMs
• Reclaimable memory visibility. Allowing for an operator to see how much memory is available in the overcommit pool, ready to be assigned to a new overcommit VM
• Balloon and swap activity. Allowing customers to be aware of ballooned memory and memory swapped to the host
• Reporting CPU and Memory overcommit ratios. Metric to express the ratio of total configured VM memory to physical cluster memory and the corresponding virtual CPU to physical CPU ratios so administrators can use this in conjunction with host or cluster-level performance statistics to detect when a cluster was creeping toward an overcommit level which could impact performance

The new metrics are organized along the natural hierarchy of an AHV deployment — VM, Host, and Cluster — so administrators can drill down from a cluster-wide capacity headline down to a single VM and back.

Memory Usage: VM Perspective

This perspective shows a stacked breakdown of each VM's configured memory into guest-used, balloon-reclaimed, and free memory as reported by the guest.

Host-Level Metrics: Per-Host Memory Balance

Host metrics are designed to cover the aggregated metrics such as cumulative configured capacity, real-time consumption, overhead accounting, balloon reclamation, and host swap. 

Cumulative VM usage with metrics aggregated across all VMs in the host are represented against the available host capacity so customers are aware of the loads across different hosts on their clusters.

Memory Usage Overview: Host Perspective

This perspective shows a per-host aggregated memory view with the slice of total physical memory consumed by allocated VM memory, VM overhead, host overhead, balloon-reclaimed memory, and swapped memory. Operators get an immediate health snapshot: a host showing considerable swap is in trouble; a host with a large reclaimable pool is a candidate for additional workloads.

Configured CPU & Overcommit Ratio

The CPU overcommit ratio is fundamental to most capacity planning to ensure the balance of VM performance versus maximizing the utilisation of resources. This graph plots the CPU overcommit ratio against total configured CPUs so CPU allocation against VMs can be increased or decreased for optimal performance of their applications. This chart also helps decide how many more CPUs can be assigned at desired overcommit ratios.

Memory Overcommit Capacity & Reclaimable

This chart provides insights into the Total Memory Overcommit Capacity available to VMs on the Host along with the potential Memory Reclaimable memory from overcommit VMs by the host. Memory reclaimable factors in the minimum sustainable capacity of 25% which remains allocated for usage by the overcommit VMs for sustainable operations on the overcommit VMs. 

Cluster-Level Metrics: The Capacity Planner's Dashboard

At the cluster level, the metrics are tuned for capacity planning and policy enforcement for organizations that might enforce internal overcommit policies. Cluster-level metrics allows an aggregated view per-cluster which allows organizations to create VMs according to resource availability on less-used clusters. Cluster utilization reports are also a very key resource for governance and compliance purposes.  

Memory Overcommit Ratio

The memory overcommit ratio at the cluster allows customers looking to optimize memory resources on the cluster with memory overcommitted VMs on the cluster monitor that overcommit ratios remain within acceptable limits for optimized performance of their workloads. This is calculated as the ratio of total configured memory of VMs on the cluster to the total aggregate memory pool size across all the hosts. 

Memory Allocation Overview:  Cumulative Host Perspective

This chart is a comprehensive snapshot of the memory usage breakdown across the cluster and is aggregated across the workloads on the hosts on the cluster to provide insights into some critical data points, such as the cumulative VM and host overheads in the cluster as well as the memory reserved for HA. 

In addition to the above, Cluster level charts and metrics are now also available for Cumulative VM and host perspective memory allocation overview, CPU overcommit ratios as well as Memory runway available to power on new VMs.

How IT administrators can leverage these metrics

The promise of Memory Overcommit has always been high VM density on the same hardware, with idle memory captured and reused. Visibility via these memory metrics will help users to adjust the density envelope in support of their operational needs.

1. High VM density, justified by data
   Infrastructure Administrators can take decisions on the number of VMs which can be turned on at the host and cluster based on the runway afforded, which is made visible by the metrics introduced.
2. Fast troubleshooting
   The updated memory usage metric, balloon visibility, and guest swap-in and swap-out rates for each VM, along with the granular memory distribution at the host and cluster level, are designed to allow operators to monitor and troubleshoot memory consumption of their applications and readjust resources accordingly, while also providing the necessary tools for troubleshooting any discrepancies.
3. Policy enforcement
   For organizations with governance frameworks, particularly around overcommit policies, alerts can be configured to fire when any cluster crosses a defined threshold. This enables genuine closed-loop overcommit management: detect → quantify → remediate, all within Prism Central.
4. Programmatic integration
   For customers integrating Nutanix telemetry into their own observability stacks (e.g., Splunk software, Datadog platform, Grafana dashboards, and in-house data warehouses), every new metric is exposed through the standard Prism Central V4 APIs for VM, Host and Cluster stats in the VM management and cluster management namespaces, respectively.
5. CapEx optimization
   Existing hosts can absorb more workloads before triggering a hardware refresh; capacity planning becomes a data-driven decision.
   Capacity planners in organizations might also want to uplevel their hardware and memory usage without compromising on performance of their applications. This workload increase can be achieved by enabling memory overcommit on their VMs and enabling as many VMs as can be accommodated to the organization’s overcommit ratio ceilings.

Conclusion

For customers in regulated industries - banking, insurance, government - the ability to prove memory headroom with our newly introduced charts is a real workflow improvement. 

Memory Overcommit has been delivering hardware savings to Nutanix customers for years. With metrics visibility this release, those savings come with the visibility they always deserved. See every megabyte and run your infrastructure with the confidence that comes from having clear visibility into where it's going.

©2026 Nutanix, Inc. All rights reserved. Nutanix, the Nutanix logo and all Nutanix product and service names mentioned are registered trademarks or trademarks of Nutanix, Inc. in the United States and other countries. All other brand names mentioned are for identification purposes only and may be the trademarks of their respective holder(s).