Nutsh, next to the other ways of driving Nutanix.

At a glance

The two questions that separate these tools are where does it run and what does it talk to. Everything else follows from those.

The Prism Central console

The console is the reference. It shows everything Nutanix has decided to show, it is supported, and every workflow Nutanix documents starts from it. If you have one Prism Central and open it twice a week, it is the right tool and Nutsh will not change your life.

Where it costs you is repetition. Every environment is a separate login in a separate tab. Every relationship is a page load. A UUID from one screen has to be pasted into the search box of another. And a browser is not a terminal: you cannot pipe a page, diff it, or drop one frame of it into an incident note.

Nutsh trades some of that coverage for speed. It shows what the v4 API exposes, and only that. Prism Central's console still reads several entity types through the older v3 groups endpoint, and those have no populated v4 collection behind them: recovery plans, DR jobs, projects, blueprints and marketplace items are the known cases. A pane in Nutsh can say none while the console lists several. Nutsh will not guess; it says which namespace answered and which did not.

ncli

ncli is the Nutanix command-line interface for one cluster: storage containers, cluster settings, protection domains, the things Prism Element manages. It runs on a Controller VM, which means an SSH session to the cluster first.

The difference in shape is that ncli is imperative and cluster-scoped. One command, one answer, one cluster. Nutsh is a view over every cluster the Prism Central manages, kept live, with the actions reachable from the row you are looking at. If you already know the exact command, ncli is quicker. If you are looking for the thing first, Nutsh is.

acli

acli is the Acropolis CLI: the AHV hypervisor's own shell, for virtual machines, networks and images on one cluster. It is the tool support asks you to run when something is wrong at the hypervisor level, and it exposes operations the API does not. It is reached by SSH to a Controller VM, and nowhere else.

Nutsh does not replace it, and could not: it never touches a CVM. What Nutsh covers is the everyday part of that surface, power state, clone, snapshot, migrate, delete, through the v4 vmm namespace, across every cluster at once, with a guardrail in front of each. For a hypervisor-level intervention on one node, acli remains the tool.

nuclei

nuclei is the Prism Central command-line interface. It runs on the Prism Central VM itself, so it needs an SSH session to that VM, and it walks the entity model one call at a time. Nutanix describes it as a tool for support engineers, and in practice that is who uses it.

It is the closest of the three in scope to Nutsh: both see everything the Prism Central manages. The differences are where they run and how they are driven. nuclei is a shell on the appliance; Nutsh is a program on your laptop that never asks for SSH access, holds several Prism Centrals as contexts, and draws the answers as tables you move through rather than listings you page through.

Terraform and Ansible

The Nutanix Terraform provider and Ansible collection are for declaring what should exist and making it so, repeatably, from version control. That is a different job from looking at what exists now, and Nutsh does not try to do it. There is no plan, no apply, and no idea of desired state.

They are complementary. A plan changes forty VMs; Nutsh is where you watch the tasks land, sort by what failed, and open the one that did not come back. If you write automation against Nutanix, you will still want something interactive next to it, and that something has until now been the browser.

k9s

Not a Nutanix tool, but the reason Nutsh looks the way it does. k9s is the terminal UI for Kubernetes: a colon prompt to jump to a resource type, contexts you switch in one command, tables driven with j and k, and a read-only mode for production. Nutsh borrows all of it on purpose, so hands that know k9s know Nutsh.

It is not a Kubernetes client. If you run Kubernetes on Nutanix, Nutsh shows you the virtual machines and storage underneath, and kubectl is still kubectl. The usage guide goes through what the two share and where the APIs underneath force them apart.

When Nutsh is the wrong tool

Cases where one of the tools above is the right answer, listed so you find out here rather than after installing it.

If none of those is you, the install command is one line, and the usage guide covers the first ten minutes.