Nutanix AHV

Clarity Transform reads inventory and placement from Nutanix Prism: AHV virtual machines, clusters, hosts, storage usage and networking. Read-only throughout, over the Prism v3 API.

Where to find it

Go to Discover → Integrations, then select the Nutanix AHV card. The card's category label is Hypervisor. The integration's page has the Endpoints and History tabs; Integrations describes the page, its grid and its row actions.

Why we do this

Beyond inventory, a virtualisation platform records placement: which virtual machine runs on which host, in which cluster, in which management domain. Placement matters for migration planning independently of application boundaries.

It tells you what moves together, what shares a failure domain, and where an application's components are spread across infrastructure in ways that constrain how it can be moved. An application map tells you what depends on what; placement tells you what is physically entangled. A wave plan needs both, and they rarely agree.

What we collect

• AHV virtual machines with their configuration and resource allocation
• Prism clusters and their hosts, with the placement relationships between them
• Storage containers and usage
• Network configuration

What it adds

Flow data, firewall policy and load balancer topology all arrive as addresses, and it is this inventory that turns them into named machines.

Where a migration is to Nutanix rather than from it, the same integration is what makes the target estate visible alongside the source, so before-and-after capacity can be compared on like terms.

What is deliberately not inferred

• No guest file systems, and no application data.
• No guest credentials and no console access.
• Nothing is written to Prism. No virtual machine is created, changed, powered on or off.
• Placement is not a dependency. Two machines on the same host are not related by that fact alone.

What we require

The requirement below is read from rb-pautol-nutanix-connect-prism.ps1 in the Runbooks repository, which is where it is maintained. If it is wrong, the runbook is what gets corrected and this page follows on the next build.

Role required: the built-in Viewer role, which is read-only. Not Prism Admin and not Cluster Admin. Across all seven AHV discovery scripts there is no PUT, PATCH or DELETE: discovery reads inventory and performance only and never writes to Prism.

The v3 list calls are POSTs and are still reads. /v3/vms/list, /v3/hosts/list, /v3/clusters/list, /v3/subnets/list and /v3/groups all take a POST body describing what to return. Worth saying out loud, because a security reviewer reading "POST" will reasonably assume otherwise and challenge the request.

The account is needed on Prism Central AND on every Prism Element, and this is the part most easily missed. Inventory comes from Prism Central. Performance history comes from the v2.0 stats API, which is a Prism Element endpoint only - Prism Central answers it with 404. So rb-pautol-nutanix-vmperformance.ps1 resolves each VM's owning cluster from the v3 response and calls that cluster's own address directly, with the same credential. Where Prism Element uses local accounts rather than the same directory as Prism Central, a PC-only account collects the whole inventory and then fails every single stats call.

Connectivity: HTTPS on TCP 9440 - not 443 - from Clarity to Prism Central, and to each Prism Element cluster VIP. A firewall rule covering only Prism Central is the common form of this mistake.

Missing stats access degrades quietly. Failed stats calls are recorded per VM and the run continues, so the outcome is a complete inventory with no performance history and no error raised. Confirm stats read from one Prism Element before the first scheduled run rather than reading an empty column as "no data retained".

Verification before handover

Run these as the system owner before handing the credential over, so a failed discovery run is never the first time anyone finds out.

1. Confirm the account authenticates to Prism Central. Log in as the account at the address the endpoint will use, on TCP 9440 rather than 443.
2. Confirm the inventory is visible. As the account, browse to the virtual machines, hosts and storage containers in scope. If they are listed, discovery will see them.
3. Confirm the same account works on a Prism Element, and that 9440 reaches it. This is the step that gets missed. Performance history is read from a Prism Element endpoint, so the credential has to be valid on each cluster and Clarity needs TCP 9440 to each cluster address, not only to Prism Central. Where Prism Element uses local accounts rather than the same directory as Prism Central, a Prism Central account collects the whole inventory and then fails every stats call.
4. Read stats for one virtual machine before the first scheduled run. Missing stats access raises no error. The run completes with a full inventory and an empty performance history, which is easily read as "nothing retained" rather than as a permission or firewall gap.

Configuring the endpoint

On the integration's Endpoints tab, select the add icon (Create New Integration Endpoints). The Create new entry form opens with these fields, in this order:

Field	Value
Name	A name for the endpoint
End Point	The Prism Central hostname or IP
Credential	The stored credential for the Viewer-role account, valid on Prism Central and on each Prism Element
Job Schedule	A five-field cron expression, for example 0 0 * * * (daily). Inventory changes continuously in most estates
Enabled	Ticked. The box is unticked when the form opens

The help texts: End Point "FQDN or IP Address of management system for technology e.g. vCenter, Nutanix Prism"; Credential "Credentials can be configured under Settings/Identity and Access Management/Credentials."; Job Schedule "Cron schedule – Use five fields: 〈mm〉 〈hh〉 〈day-of-month〉 〈month〉 〈weekday〉".

The Credential list offers the credentials stored under Settings → Identity & Access Management → Credentials, so create the credential there first.

No field is marked as required. Technology is set by the card and is hidden in the form. Select Save to create the endpoint, or Cancel to close the form. The edit icon opens the same fields as Edit entry.

Removing the access

Delete the account in Prism Central, and on each Prism Element where it was created locally. Nothing else is left behind: Clarity creates no objects and holds no session once a run ends. Then, in Clarity, remove the endpoint (select its row on the Endpoints tab, then Remove selected) or clear its Enabled box, and remove the credential under Settings → Identity & Access Management → Credentials.

Troubleshooting

Symptom	Cause
Cannot reach the endpoint at all	The Prism API is on TCP 9440, not 443. Check the firewall rule specifies that port, and that it covers every Prism Element as well as Prism Central.
Full inventory, no performance history, no error	Performance comes from a Prism Element endpoint: either the credential is not valid on that cluster, or TCP 9440 to the cluster address is not open.
Authentication fails	Wrong credential, or the account is local to a Prism Element rather than to the Prism Central being addressed.
Some clusters missing	The account's visibility does not cover them, or they are registered to a different Prism Central.
A security review challenges the POST requests	The v3 list calls take a POST body describing what to return. They are reads. The Viewer role grants no write anywhere, and the discovery scripts issue no PUT, PATCH or DELETE.
Certificate error on connect	Prism is using a self-signed or untrusted certificate. Trust the CA on the Clarity host.