Team Leader - Nutanix Technology Champion - Nutanix NTC Storyteller

Julien DUMUR
Infrastructure in a Nutshell

ahv

Configuring Your Windows PC to Query the Nutanix API (WSL & Postman)

Published: 6 March 2026
Written by Julien D.
No comments
Categories: Nutanix AHV EN, Nutanix EN
nutanix ahv api

I’ll be honest: a while ago, development and APIs weren’t exactly my cup of tea. My playground was the console, SSH, commands typed on the fly. But with the future (and inevitable) blocking of SSH access on Prism Element and Prism Central, I had no choice: I had to get serious about it. And if I’m going to dive into the world of Nutanix APIs from my Windows PC, I might as well do it with the right tools to avoid tearing my hair out. In this article, I’ll show you how I equipped myself with the perfect tools to query Nutanix APIs.

Why Optimize Your Windows Environment for APIs?

For years, my reflex as a sysadmin facing a complex or repetitive task on Nutanix was the same: open PuTTY, connect via SSH to a Controller VM (CVM), and run ncli or acli commands on the fly. It was fast, it was efficient.

But I’ll be direct: that era is over. Nutanix is making a major security shift. SSH access to clusters will be disabled in one of the upcoming releases, relegated to the simple rank of emergency access for support. The only sustainable, supported, and scalable method to interact with your infrastructure is the API. Whether it’s the v2 API to drive a local cluster via Prism Element, or the v3 APIs on Prism Central, API automation has become the norm.

The problem? Windows hasn’t historically been the best student for handling complex web requests in the command line. PowerShell has made huge progress with Invoke-RestMethod, but when it comes to testing, debugging, and formatting nested JSON, nothing beats a solid Linux foundation coupled with a graphical API client.

That’s where our two best allies come in: WSL (Windows Subsystem for Linux) for the power of the native command line, and Postman for visual exploration of Nutanix APIs. Let’s see how to put all this together.

Solution 1: The System Foundation with WSL (Windows Subsystem for Linux)

How to avoid tearing your hair out with the quotes of a curl command under the Windows command prompt (cmd) or fighting with character escaping under PowerShell? The most elegant and robust solution today is to use the Windows Subsystem for Linux (WSL).

Deploying WSL and Ubuntu in Minutes

The installation is ultra-simple on recent versions of Windows 10 and 11. Open a PowerShell console as an administrator and simply type this magic command:

wsl --install ubuntu

Then restart your PC. You now have a functional Ubuntu distribution, fully integrated into your Windows, without the heaviness of a classic virtual machine. It’s the perfect environment to run your future Bash or Python scripts targeting the Nutanix infrastructure.

Look for the “Ubuntu” icon in the Windows start menu to launch the command prompt on the subsystem.

The Essential Packages: curl and jq

Once in your new Ubuntu terminal, you are missing two vital tools to dialogue with REST APIs: curl (the standard for forging web requests) and jq (the absolute Swiss Army knife for manipulating, filtering, and formatting JSON responses). Install them with these command lines:

sudo apt update && sudo apt upgrade
sudo apt install curl jq -y

Why is jq so critical in our line of work? Let me share a concrete field situation with you. JSON responses returned by Prism Element or Prism Central are often extremely verbose. If I simply want to retrieve the unique identifier (UUID) of my cluster via the v2 API to use it in a script, without drowning in hundreds of lines of configuration, here is the exact command I use:

curl -k -u admin:MyPassword -X GET https://<YOUR_PRISM_ELEMENT_IP>:9440/api/nutanix/v2.0/cluster | jq '.cluster_uuid'

The -k parameter is crucial here: it ignores the SSL certificate warning (which is self-signed by default on Nutanix), and the | jq '.cluster_uuid' instantly filters the raw response to return only the targeted information (in the example below: "00064a67-579d-c757-5883-002590b8ef5a"). It’s clean, neat, and perfectly integrable into a variable to automate a deployment workflow, for example.

curl call to the cluster v2 API from WSL

Solution 2: The Must-Have Graphical API Client: Postman

The command line is great for running production scripts. But when it comes to exploring a new API, testing the parameters of a complex request, or analyzing the structure of a 500-line JSON payload, I prefer a graphical interface. And in this area, Postman is perfectly suited. You can download and install it in seconds from their official website.

Configuring Your First Workspace

The first mistake I made when starting with the Nutanix API (and with Postman in general), is hardcoding my IP addresses, usernames, and passwords in every request. Never do that! Not only is it tedious if you switch clusters, but it’s especially a major risk of information leakage if you share your screen or your collections.

Postman offers a vital feature: Environments. Create a new environment (e.g., “Prod Cluster”) and define three variables in it:

  • cluster_ip: The IP address of your Prism Element or Prism Central.
  • username: Your service account (avoid using the default admin account if possible).
  • password: The associated password (to be configured as “Secret” type to hide it).

From now on, in your requests, you will no longer use the raw URL, but the call to variables between double curly braces: https://{{cluster_ip}}:9440/api/nutanix/v2.0/...

Postman environment variables for the cluster

The Expert’s Trick: Importing the Prism Central Swagger

Here is my real “trick” to save you hours. Nutanix APIs, particularly the v3 APIs on Prism Central, are extremely vast. Rather than creating your GET, POST, or PUT requests one by one by laboriously reading the documentation on the Nutanix.dev portal, did you know that you could suck all the configuration directly from your own cluster?

The Prism Central API exposes its OpenAPI specification (Swagger). In Postman, click on the “File > Import” button in the top left menu, choose “Link”, and simply paste this URL (replacing the IP with your Prism Central’s IP): https://<PRISM_CENTRAL_IP>:9440/static/v3/swagger.json

Importing the Nutanix Swagger into Postman

Let the magic happen: Postman will query your cluster and automatically generate a complete Collection containing absolutely all possible v3 API requests, preformatted with the right headers and sample payloads. It’s a massive time saver for exploration!

Postman collection generated from the Swagger

Test: The First API Call from Postman

Now that the tooling is ready and my variables are configured, it’s time to make the first graphical request to the cluster to retrieve its global information.

Managing Authentication and Bypassing the SSL Trap

Create a new request in Postman (+ button or New > HTTP Request). Select the GET method and enter the following URL using our variable: https://{{cluster_ip}}:9440/api/nutanix/v2.0/cluster

Before clicking “Send”, we have two settings left to make:

  1. Authentication: Go to the Authorization tab, choose the Basic Auth type. In the Username and Password fields, type {{username}} and {{password}} respectively. Postman will replace these values on the fly.
  2. The SSL Certificate: By default, Nutanix uses self-signed certificates. If you run the request now, Postman will block the call with a security error. Go to File > Settings (or the gear icon), General tab, and disable the “SSL certificate verification” option. This is the graphical equivalent of our -k parameter in curl.

Click Send. If everything is green (Status 200 OK), you should see a beautiful formatted JSON appear at the bottom, containing your cluster’s UUID, its name, its AOS version, and its virtual addresses. Congratulations, your workstation is communicating with Nutanix!

Cluster JSON response in Postman

Basic Auth vs JSESSIONID

If you are just starting out, the Basic Auth method (which sends your credentials with each request) is perfect. But beware: this method has an impact.

Why? Because every time you make an API call in Basic Auth, the CVM’s Acropolis service must validate your credentials with the authentication module (and often, these credentials will be linked to an Active Directory via LDAP). If you run a script that makes 500 requests in a row to inventory VMs, you will trigger 500 identity validations. This unnecessarily saturates the CVMs and your domain controllers.

The best practice if you script massively: Authenticate only once, and use session Cookies! When you make an initial authentication request or query the API, Nutanix sends you back a cookie named JSESSIONID. Postman stores it automatically and uses it for subsequent requests in your collection. In your future Bash/Python scripts, always remember to retrieve this cookie during the first call, and pass it in the Headers of your subsequent calls. You will drastically relieve the management plane of your cluster!

Conclusion: Security Reminder and Advanced Usage

All the tools are now in place to free myself as much as possible from SSH during my next troubleshooting sessions.

I must give a fundamental security reminder. Postman allows you to export your collections to share them with your colleagues or back them up. It’s great for teamwork. But beware: if you haven’t used environment variables as we saw earlier, and you typed your passwords “hardcoded” directly in the Authorization tab of your requests, they will be exported in clear text in the collection’s JSON file.

Always ensure your “Secrets” remain in your local Environment configuration (which, by default, does not export current values with the collection). I’ve seen too many admin passwords lying around on the network because of this!

Now, all I have to do is look into the scripting and automation part to be able to develop applications that will help me drive, audit, and configure my Nutanix clusters.

But that will be the subject of a future article! Until then, happy querying to all.

Read More

Nutanix AHV: deploy an Ubuntu 24.04 VM with a NVidia Tesla P4 GPU

Published: 27 February 2026
Written by Julien D.
No comments
Categories: Nutanix AHV EN, Nutanix EN
GPU Nutanix AHV Linux

Integrating graphics processing power within virtualized environments has become a must. Whether it’s to run Artificial Intelligence models, Machine Learning, or simply for intensive video processing, our virtual machines increasingly need muscle.

When I talk with clients, I often get questions about this: how do you assign a physical graphics card to a VM in a simple and performant way?

Today, I suggest we look together at how to deploy an NVIDIA Tesla P4 GPU on an Ubuntu Server 24.04 VM hosted on Nutanix AHV, using “Passthrough” mode.

1. Prerequisites

Before getting our hands dirty, let’s take a moment to check our equipment. Good preparation is half the work done! I myself have lost hours in the past due to a simple forgotten prerequisite.

To follow this tutorial, you will need:

  • A Nutanix node (physical cluster) equipped with at least one NVIDIA Tesla P4 card.
  • A virtual machine running Ubuntu Server 24.04.
  • Functional SSH access to this VM with sudo privileges.

Although Nutanix AHV handles this transparently for you, keep in mind that Passthrough mode relies on specific hardware instructions. It requires that I/O virtualization extensions (VT-d for Intel or AMD-Vi for AMD) are properly enabled in the BIOS of your physical node. If you ever build a “home-lab” cluster, this is the first thing to check!

2. Nutanix Configuration: Passthrough Mode

Now that our foundation is solid, let’s move on to the administration interface. This is where the magic happens. Whether you use Prism Element or Prism Central, the logic remains the same. First, make sure your virtual machine is powered off.

Go to your VM’s settings, select “Update”, and scroll down to the “GPUs” section. Click on “Add GPU”.

In the window that opens, the choice is crucial: in the “GPU Type” drop-down menu, select Passthrough mode, then choose your Tesla P4 from the list.

Adding a Tesla P4 GPU in Passthrough to the VM

Passthrough mode is a special feature: it allows you to “hand over the keys” of the physical graphics card directly to the virtual machine. The guest OS has the illusion (and the benefits) of physically owning the card.

You might be wondering why we prefer Passthrough over vGPU? It’s a matter of use case, but also architecture.

vGPU allows you to virtually slice a card to share it among several VMs, which is great for VDI, but it requires the installation and maintenance of an NVIDIA license server (vGPU Software).

Passthrough, on the other hand, dedicates 100% of the Tesla P4’s power to our Ubuntu VM, without any additional license server. For a raw single-VM performance need, it’s clearly the best option.

3. Preparation and Ubuntu 24.04 Update

Once the GPU is attached, save the configuration, power on your VM, and connect via SSH.

Before we rush into installing the NVIDIA drivers, there’s one step I absolutely never skip: updating the system.

Simply type this command:

sudo apt update && sudo apt upgrade -y

Proprietary NVIDIA drivers rely on the DKMS (Dynamic Kernel Module Support) system to compile kernel modules on the fly during installation.

If your kernel headers are not perfectly synchronized with your current Linux kernel version, the installation will fail silently. A freshly updated system is your best guarantee for a clean, hitch-free compilation!

4. NVIDIA Drivers Installation (Server Branch)

Now that our system is clean and updated, let’s move on to the main course. On Ubuntu, we often have the reflex to use the ubuntu-drivers autoinstall command or install the latest trendy “desktop” version. Let me stop you right there!

For a server, especially in production, stability is key. That’s why we are going to install the “Server” branch of the driver. Type the following command:

sudo apt install nvidia-driver-535-server -y

💡 The Expert’s Tip: Why specifically the “server” package? NVIDIA maintains specific driver branches for data centers. The “Server” branch (or Tesla driver) is designed for long lifecycles (LTS) and minimizes the risk of regression. Installing a “Desktop” driver on a hypervisor or an AI server means risking a minor update breaking your production environment on a Friday at 5 PM!

Let the installation finish (this may take a few minutes while DKMS compiles the module for your kernel). Once completed, a reboot is mandatory to properly load the driver:

sudo reboot

5. Validation

After the reboot, reconnect via SSH to your virtual machine. To verify that the OS, the driver, and the hardware are communicating perfectly, NVIDIA provides us with an essential command-line tool:

nvidia-smi

If all went well, you should see a beautiful ASCII dashboard appear.

nvidia-smi output with the Tesla P4

💡 Explications: At the top right, note the CUDA Version (here 12.2): this is the maximum version of the CUDA API supported by this driver, crucial info for AI developers. Also look at the Perf column: it indicates “P0”, which corresponds to the maximum performance state (the “P-states” range from P0 to P12 for power saving). If your card stays stuck on a low P-state while under load, there’s a hardware or thermal issue! Finally, this output confirms that the OS is ready to host the NVIDIA Container Toolkit (for Docker with GPU).

Conclusion

And there you have it! In a few simple steps, we successfully physically presented our NVIDIA Tesla P4 GPU to our Ubuntu 24.04 VM under Nutanix AHV. Passthrough mode allowed us to achieve a high-performance, zero-latency configuration without the overhead of an external license server.

Our Tesla P4 is now properly installed! The next logical step? Deploying LLMs (Large Language Models) or compute-heavy applications in isolated containers. But that will be for a future article on the blog!

Read More

Hyperconvergence (HCI): The End of the Monolithic Era

Published: 12 February 2026
Written by Julien D.
No comments
Categories: Nutanix AHV EN, Nutanix EN
Hyperconvergence, the end of the monolithic era

I will never forget the day the reality of hyperconvergence hit me. We were in the middle of an infrastructure migration. On one side, we had two full 42U racks from the 3-tier era, packed with servers and storage arrays. On the other side, to replace them, we only needed… 6U.

Two 2U Nutanix blocks (with 4 nodes in each block) and two Top of Rack switches. That was it. 84 rack units reduced to 6. The contrast was so violent it almost felt suspicious. How could such a small physical footprint replace our historic cabinets?

But make no mistake. Beneath this apparent simplicity lay a major technological rupture. We had moved from a “Hardware-Defined” era, where intelligence resided in expensive proprietary ASICs, to a “Software-Defined” era.

This void in the racks wasn’t just aesthetic. It told another story: one of exploding density, radically changing the economic equation of the datacenter. Less cooling, less floor space, less power consumption for tenfold computing power. The storage array hadn’t disappeared: it had been absorbed and virtualized by software.

Legacy architecture footprint versus hyperconvergence

The Legacy of Web Giants

To understand where this magic comes from, we have to go back to the early 2000s, far from air-conditioned enterprise server rooms, into the labs of Google and Amazon.

At that time, these giants were hitting a wall: the 3-tier model didn’t scale. To index the entire web, using traditional storage arrays like EMC or NetApp would have cost an astronomical amount. They had to find another way.

Their stroke of genius was to flip the table. Instead of buying “Premium” hardware designed never to fail (and sold at a gold price), they decided to use “Commodity Hardware”. Standard x86 servers, cheap, almost disposable.

The philosophy changed completely: hardware will fail. It is a statistical certainty. Rather than fighting this reality with redundant components, they decided to manage failure at the software level.

For purists and tech historians, the founding moment is captured in a PDF document published in October 2003: “The Google File System“ (SOSP’03). This research paper is the bible of modern infrastructure. It describes a system where thousands of unreliable hard drives are aggregated by intelligent software that ensures resilience. If a drive dies? The system doesn’t care. No need to rush to replace the disk at 3 AM. The software has already replicated the data elsewhere.

Hyperconvergence is simply the arrival of this “Web Scale” technology, packaged and democratized for our enterprises.

Anatomy of an HCI Node: How Does It Work?

Concretely, what changes at the hardware level? In a hyperconverged infrastructure, we no longer separate Compute and Storage. Everything is reunited in the same chassis, called a “Node”.

Each node contains its own processors, RAM, and its own disks (SSD, NVMe, HDD). But unlike a classic server, these disks aren’t just for installing the local OS. They are aggregated with the disks of other nodes in the cluster to form a global storage pool.

This is where the real revolution comes in: the CVM (Controller VM).

Imagine taking the physical controllers of your old SAN array (the compute part) and turning them into software. On each physical server in the cluster, a special virtual machine (the CVM) runs permanently. It is the conductor.

For the technical expert, the feat lies in hardware management. The hypervisor (ESXi or AHV) does not manage the storage disks. Thanks to a technology called PCI Passthrough (or I/O Passthrough), the CVM bypasses the hypervisor to speak directly to the disks. Result: raw performance without the classic virtualization overhead.

Cutaway of an HCI node with the CVM and PCI Passthrough

The Strengths of Hyperconvergence

Beyond the hype, three technical arguments have hit the mark in enterprises.

1. Scale-Out (The LEGO Approach)

Gone is the headache of 5-year sizing. With 3-Tier, when the array was full, it was panic mode (Scale-Up). With HCI, if you need more resources, you buy a new node and plug it in. The cluster automatically absorbs the new CPU power and storage capacity. It is linear and predictable growth.

Scale-out by stacking nodes

2. Data Locality

This is the Holy Grail of performance. In a classic architecture, data had to cross the SAN network to reach the processor. With HCI, software intelligence ensures that data used by a VM is (whenever possible) stored on the disks of the physical server where it is running. The path is near-instantaneous. The network is no longer a bottleneck.

3. Distributed Rebuild (Many-to-Many)

This is often the argument that finally convinces administrators traumatized by RAID rebuilds. On a classic array (RAID 5 or 6), if a 4TB drive breaks, a single “hot spare” drive has to rewrite everything. This can take days, during which performance collapses. In HCI, data is replicated in chunks all over the cluster. If a drive dies, all other disks in all other nodes participate simultaneously in reconstructing the missing data. We move from a “1 to 1” problem to a “Many to Many” solution. Result: resilience is restored in minutes.

Classic RAID rebuild versus HCI distributed rebuild

The Weaknesses: What Marketing Forgets to Mention

If hyperconvergence seems magical, it is not without flaws. As an expert, it is crucial to understand the trade-offs of this architecture.

The first is the “CVM Tax”. Intelligence isn’t free. Since the storage controller is now software, it consumes CPU and RAM resources that are no longer available for your applications. On very small clusters, reserving 20GB or 24GB of RAM per node just to “run the shop” can seem heavy, even if it is the price of peace of mind.

The second technical limitation is the critical dependence on “East-West” network traffic. In a 3-Tier array, replication traffic remained confined within the array. In HCI, to secure data (RF2 or RF3), the CVM must write it locally but also immediately send it over the network to another node. If your 10/25 GbE network is unstable or poorly configured, the entire performance and stability of the cluster collapses. The network is no longer a simple commodity; it is the nervous system of your cluster. I repeat it to every client: an HCI cluster is 80% network. If your network has a problem, your HCI cluster has a problem.

Nutanix, The Pioneer

Hyperconvergence marked the end of an era. It proved that software could supplant specialized hardware, transforming our rigid datacenters into agile private clouds.

But an idea, however brilliant (like the Google File System), is useless if it remains confined to a research lab. Someone had to take these complex concepts and make them accessible to any system administrator in less than an hour.

That is where Nutanix comes in.

Founded by former Google employees who had worked on GFS, this company created NDFS (Nutanix Distributed File System). They succeeded in the crazy bet of running a “Google-type” infrastructure on standard Dell, HP, or Lenovo servers.

How did Nutanix manage to become the undisputed leader of this market, surviving even the assault of VMware with vSAN? That is what we will dissect in the next article of this series.

Read More

Nutanix AHV : How to Gracefully Shutdown a Cluster

Published: 10 February 2026
Written by Julien D.
No comments
Categories: Nutanix AHV EN, Nutanix EN
Gracefully shutting down a Nutanix AHV cluster

Let’s be honest: shutting down a complete Nutanix cluster is always a bit stressful. Even after 15 years in the business. Why? Because even with the best HCI technology on the market, cutting the power on an IT infrastructure is never trivial.

I’ve seen too many “cowboys” pull the plug or perform a brutal “Shutdown” via IPMI, thinking data resiliency would handle the rest. Spoiler alert: this often ends with Level 3 Nutanix support on the line to recover corrupt Cassandra metadata or with the loss of one or more disks.

This guide is my lifeline to ensure my cluster restarts without issues. No GUI, no Prism Element for the critical steps. We open the terminal, connect via SSH, and do it properly.

Phase 1: Health Checks

Before even thinking about stopping a single VM, you must ensure the cluster is capable of stopping (and more importantly, restarting). If your cluster is already suffering, shutting it down is not always a good option.

1.1 SSH Connection to the CVM

Open your favorite terminal (PuTTY works just fine) and connect via SSH to the cluster’s virtual IP address (Cluster VIP) with the user nutanix.

1.2 Nutanix Cluster Checks (NCC)

To ensure the cluster is healthy, it is necessary to run an NCC. Run a full check:

ncc health_checks run_all

My advice: Don’t just skim through the report. If you have a “FAIL” on Cassandra, Zookeeper, or Metadata, STOP. Fix it before shutting down. A warning about a full disk or an old NTP alert is acceptable. But data integrity is non-negotiable.

1.3 Resiliency Verification

The Prism dashboard is pretty; it tells you “Data Resiliency Status: OK”. That’s good, but it’s not precise enough for a total shutdown. I want to know if my data is truly synchronized, right now.

Type this command and look it in the eye:

ncli cluster get-domain-fault-tolerance-status type=node

What you need to see: A line indicating Current Fault Tolerance: 2 (or 1 depending on your RF configuration).

If you see a state indicating a rebuild in progress, do not shut down the cluster and wait for the rebuild to finish.

Phase 2: Shutting Down Workloads

Once the cluster is validated as healthy, we move on to the virtual machines. The classic mistake is rushing to stop the nodes, but this will be refused if virtual machines are still running on the cluster.

2.1 The Battle Order

Start by shutting down your test/dev environments, then application servers, and finally databases. It’s common sense, but it’s always good to be reminded.

Once all production machines are off, you can now shut down the remaining “tooling” VMs of your infrastructure: AD, DNS, firewalls…

2.2 Managing Prism Central

Connect to Prism Central via SSH with the nutanix account, then run the stop command:

cluster stop

Wait for the PCVM services to stop and verify that the cluster is indeed stopped:

cluster status

If all services are stopped and the cluster status is “stop”, we can now proceed to shut down the PCVM:

sudo shutdown -h now

Phase 3: Stopping Nutanix Services (“Cluster Stop”)

Your VMs and Prism Central are off. Your hosts are running nothing but CVMs (Controller VMs). This is the critical moment. We never perform an OS shutdown of the CVMs without first stopping the cluster services properly.

Why? Because a brutal shutdown of CVMs can lead to data corruption or metadata inconsistencies that might require support intervention.

3.1 Stopping the Cluster

Reconnect to your Nutanix cluster VIP and simply type:

cluster stop

The system will ask for confirmation before launching operations. Type Y.

This command orders each CVM to stop its services in a precise order. The Stargate service (which handles storage I/O) ensures everything is “flushed” to disk before shutting down.

You will see lines scrolling by indicating the stop of Zeus, Scavenger, Cassandra, etc. Be patient. Depending on the cluster size, this can take 2 to 5 minutes.

3.2 Verification

Once the operation is complete, check the actual state of services:

cluster status

What you need to see: A list of services for each CVM. They must all be in the DOWN state, with the potential exception of the Genesis service which may remain UP; this is normal.

If you see other services still UP, wait a minute and run the check again. Do not proceed until the cluster is logically fully stopped.

Phase 4: Shutting Down CVMs and Physical Nodes

We are at the end of the tunnel. The cluster is logically stopped. Only empty shells remain: the CVMs (which are Linux VMs, let’s not forget) and the hypervisors.

4.1 Stopping CVMs

You must now connect to each CVM individually (via its IP, no longer via the VIP) and run the shutdown command.

The official command:

cvm_shutdown -P now

The cvm_shutdown command contains specific hooks to notify the hypervisor. Repeat the operation on each node of the cluster.

4.2 Stopping Hypervisors

Once the CVMs are off, connect to your hosts (via SSH or IPMI) and on each of them type the following command:

shutdown -h now

The Expert Nugget: The Automation Script ⚡

Do you have a 16-node cluster and don’t feel like connecting 32 times (16 CVM + 16 Hosts)? I get it.

Here is a script to run from any CVM in the cluster that will shut down all CVMs, then all AHV hosts.

⚠️ WARNING: This script asks no questions. Ensure you have validated Phase 3 (cluster stop) before launching this, otherwise, a crash is guaranteed.

The “Kill Switch” Script (For AHV)

From a CVM, this script retrieves the IPs of other CVMs and hosts, then sends the shutdown order in sequence.

for svmip in `svmips`; do ssh -q nutanix@$svmip "sudo /usr/sbin/shutdown +1 ; hostname"; done
for hostip in `hostips`; do ssh -q root@$hostip "/usr/sbin/shutdown +3 ; hostname"; done
  • The first command orders the shutdown of CVMs after a one-minute delay.
  • The second command orders the shutdown of nodes after a 3-minute delay.

Once you have launched the commands, you will lose connection after one minute. You can then monitor the shutdown of your nodes from their respective IPMI interfaces.

Phase 5: Powering Back Up (Cold Boot)

The maintenance period is over. What do we do? Press ON and pray? No, we follow the reverse order.

  1. Physical Network: Turn on your Top-of-Rack switches first. If the network isn’t there, the nodes won’t see each other upon booting.
  2. IPMI / Physical: Turn on the physical nodes.
  3. Patience: AHV will boot, then automatically start the CVM.
    • Tip: Don’t touch anything for 10 minutes. Let the CVMs form the cluster.
  4. Starting the Cluster: Connect via SSH to a CVM. Verify that all CVMs are up (svmips should list them all). Then:cluster start
  5. Verify that the cluster has started properly with the command:cluster status
  6. Starting Workloads: Once the cluster is UP, power on the PCVM first, then your VMs (Infra first, Appli second).

Conclusion

Shutting down a Nutanix cluster is a simple procedure but requires good sequencing. It’s not complicated, but it doesn’t forgive impatience. If you follow these steps, you’ll sleep soundly during the power outage.

Read More

Nutanix Supervision with Centreon: From a global “Cluster” view to Node-level visibility

Published: 5 February 2026
Written by Julien D.
No comments
Categories: Nutanix AHV EN, Nutanix EN, Supervision
nutanix centreon supervision snmp

We’ve all been there. That moment when your monitoring dashboard shows a beautiful green circle for your Nutanix cluster, while in reality, one of the nodes is struggling. That’s exactly what happened to me recently.

When I integrated Nutanix into my infrastructure, my first instinct was to pull out Centreon. Why? Because it’s my Swiss Army knife for monitoring. But I quickly realized that the “standard” method of adding a cluster locks us into an illusion of security. We see the “whole,” but we miss the “detail.”

Prism Element dashboard of a 3-node cluster

In this feedback report, I’ll share my experience with Nutanix Centreon monitoring and explain why you should stop monitoring your cluster solely through its Virtual IP (VIP) and switch to a granular node-by-node strategy.

Why the “default” configuration left me wanting more

When installing the Nutanix Plugin Pack on Centreon, the documentation naturally guides you toward adding a single host representing the cluster.

How the standard Nutanix Plugin Pack works

The classic method involves querying the cluster’s Virtual IP (VIP) or the IP of one of the CVMs (Controller VM). It’s simple and fast: you enter the SNMP community, apply the template, and the services appear. You then monitor global CPU usage, average storage latency, and the general status reported by Prism.

The “Black Box” problem

This is where the trouble starts. By querying only the VIP, you are actually querying an SNMP agent that aggregates data. If you have a 3-node cluster, the monitoring will tell you that the cluster-wide memory is “OK.” But what about the memory load on node #3?

Cluster services in Centreon with one critical VM

This is what I call the “black box” effect. Nutanix’s Shared Nothing architecture is a strength for resilience, but it can become a blind spot for monitoring if you don’t drill down to the physical layer. For an expert, knowing the cluster is “Up” is not enough; we need to know which specific physical component requires intervention before redundancy is compromised.

Decoupling monitoring for granular visibility

To break out of this deadlock, I changed my approach: treating each node as its own entity in Centreon. Here’s how I did it.

Step 1: Setting the stage on Prism Element

Before touching Centreon, you must ensure Nutanix is ready to talk. Head to Prism Element, in the SNMP settings. Here, I configured SNMP v2c access (or v3 if you want to max out security).

SNMP v2c configuration in Prism Element

Check out my dedicated articles if you need details on how to configure SNMP v2c or SNMP v3 on your Nutanix cluster.

Step 2: The “Node by Node” addition strategy in Centreon

This is where the magic happens. Instead of creating a single “Cluster-Nutanix” host, I created as many hosts as I have physical nodes (e.g., cluster-2170_n1, cluster-2170_n2, etc.).

Host Configuration: Each host points to the cluster’s VIP IP address or the specific node’s CVM IP. By default, this will pull the same global information, but stay tuned.

Applying Templates: I apply the Virt-Nutanix-Hypervisor-Snmp-Custom template.

Surgical Filtering: This is the key secret. In the “Host check options,” I apply the custom macro FILTERNAME. This allows me to specify the exact name of the host to monitor. The plugin then filters the SNMP data sent by the VIP to return only what concerns my specific node.

SNMPEXTRAOPTIONS and FILTERNAME macros on a node host

Step 3: The trick to maintaining Cluster consistency

To keep an overview, I use Host Groups in Centreon. I created a group named HG-Cluster-Nutanix-Prod containing my 3 nodes. This allows me to create aggregated dashboards while keeping the “drill-down” capability (clicking to see details) for each physical machine.

Centreon dashboard for the CLUSTER-2170 cluster

Immediate benefits: Dashboarding and Peace of Mind

Since I switched to this configuration, my daily life as a sysadmin has radically changed:

Granular performance analysis: I can now identify a node consuming abnormally more RAM or CPU than its neighbors. It’s the perfect tool for detecting a “hot point” or a VM distribution issue.

Increased responsiveness: When something goes wrong, Centreon sends me an alert with the specific node name (n1, n2, etc.). No more guessing games in Prism Element to find out where to focus my search.

Clean history: I have metric graphs per physical server, which greatly facilitates Capacity Planning and troubleshooting.

Per-node monitored services in Centreon

Per-node CPU usage chart in Centreon

Conclusion

If you manage Nutanix, don’t settle for the superficial view offered by the VIP IP alone. By taking 10 minutes to declare your hosts individually in Centreon with the FILTERNAME macro, you move from “passive” monitoring to a true control tower.

My verdict is clear: node-level monitoring is the only way to guarantee true high availability and sleep soundly at night.

Read More

3-Tier Architecture: Anatomy, Strengths, and Limits of the Historic Virtualization Standard

Published: 3 February 2026
Written by Julien D.
No comments
Categories: Nutanix AHV EN, Nutanix EN
3-tier virtualization architecture

I still remember my first time entering a “serious” server room back in the mid-2000s. What struck me wasn’t so much the deafening roar of the air conditioning, but the physical density of the infrastructure.

Back then, to run a few hundred virtual machines, you didn’t just need “a cluster.” You needed entire rows. Power-hungry Blade Centers, monstrous Fibre Channel switches with their characteristic orange cables, and above all, sitting in the center of the room like a sacred totem: the Storage Array. Entire cabinets filled with 10k RPM mechanical disks, weighing as much as a small car and consuming as many ‘U’ (rack units) as possible.

This is what we call the 3-Tier architecture. While Hyperconvergence (HCI) and Public Cloud seem to be the norm today, it is crucial to understand that 3-Tier was the backbone of enterprise IT for nearly 20 years. To understand this architecture is to understand where we come from, and why we sought to change it.

In this article, the first in a series that will present the evolution of 3-tier virtualization infrastructures towards Nutanix hyperconverged infrastructures, we will factually dissect this standard: how it works, why it dominated the market, and the technical limits that eventually rendered it obsolete for modern workloads.

Genesis: Why Did We Build It This Way?

To understand 3-Tier, you have to go back to the pre-virtualization era. A physical server hosted a single application (Windows + SQL, for example). It was the “Silo” model. Inefficient, expensive, and a nightmare to manage.

Virtualization (led by VMware) arrived with a promise: consolidate multiple virtual servers onto a single physical server. But for this magic to happen, there was an absolute technical condition: mobility.

For a VM to move from physical server A to physical server B without service interruption (the famous vMotion), both servers had to see exactly the same data, at the same moment.

This is where the architecture split into three distinct layers:

  1. We removed the disks from the servers (which now only do computing).
  2. We centralized all data in external shared storage (the Array).
  3. We connected everything via a dedicated ultra-fast network (the SAN).

It was a revolution: the server became “disposable,” or at least interchangeable, because it no longer held the data. But this centralization created a single point of complexity and performance: shared storage. It is the heart of the reactor, but also its Achilles’ heel.

The Anatomy of 3-Tier: Decoupling the Layers

If we were to draw this architecture, it would look like a three-layer cake, where each layer speaks a different language.

Infographic of the anatomy of a 3-tier architecture

1. The Compute Layer

At the very top, we have the physical servers (Hosts). They run the hypervisor (ESXi, Hyper-V, KVM). Their role is purely mathematical: providing CPU and RAM to the virtual machines.

These servers are “Stateless”. They store nothing persistent. If a server burns out, it doesn’t matter: we restart the VMs on its neighbor (HA).

This logic was pushed to the extreme with “Boot from SAN”. We even ended up removing the small local disks (SD cards or SATA DOM) that contained the hypervisor OS so that the server was a total empty shell, loading its own operating system from the distant storage array. A technical feat, but a nightmare in case of SAN connectivity loss.

2. The Network Layer (SAN)

In the middle sits the Storage Area Network. It is the highway that transports data between the servers and the array. Historically, this didn’t go through classic Ethernet (too unstable at the time), but through a dedicated protocol: Fibre Channel (FC).

It is a deterministic and lossless network. Unlike Ethernet which does “best effort,” FC guarantees that packets arrive in order.

If you have administered SAN, you know the pain of Zoning. You had to manually configure on the switches which port (WWN) was allowed to talk to which other port. A single digit error in a 16-character hexadecimal address, and your production cluster would stop dead. It was a task so complex that it often required a dedicated team (“The SAN Team”).

3. The Storage Layer

At the very bottom, the Storage Array. It is a giant computer specialized in writing and reading blocks of data. It contains controllers (the brains) and disk shelves (the capacity).

The array aggregates dozens or even hundreds of physical disks to create large virtual volumes (LUNs) that it presents to the servers. It ensures data protection via hardware RAID.

All the intelligence resides in two controllers (often in Active/Passive or Asymmetric Active/Active mode). This is an architectural bottleneck: no matter if you have 500 ultra-fast SSDs behind them, if your two controllers saturate in CPU or cache, the entire infrastructure slows down. This is called the “Front-end bottleneck”.

The Strengths: Why This Model Ruled the World

It’s easy to criticize 3-Tier with our 2024 eyes, but we must recognize that it brought incredible stability.

  1. Robustness and Maturity: This is hardware designed never to fail. Storage arrays have redundant components everywhere (power supplies, fans, controllers, access paths). We talk about “Five Nines” (99.999% availability).
  2. Fault Isolation: If a server crashes, the storage lives on. If a disk breaks, hardware RAID rebuilds it without the server even noticing (or almost).
  3. Scale-Up Independence: This was the king argument. Running out of space but your CPUs are idling? You just buy an extra disk shelf. Running out of power but have plenty of space? You add a server. You could size each tier independently.
Infographic of the strengths of the 3-tier architecture

The Weaknesses: The Other Side of the Coin

Despite its robustness, the 3-Tier model began to show serious signs of fatigue in the face of modern virtualization. For us admins, this translated into shortened nights and a few premature gray hairs.

Infographic of the weaknesses of the 3-tier architecture

Operational Complexity

The greatest enemy of 3-tier is not failure, it’s the update. Imagine having to update your hypervisor version (ESXi). You can’t just click “Update.” You have to consult the HCL (Hardware Compatibility List). Is my new HBA card driver compatible with my Fibre Channel switch firmware, which itself must be compatible with my storage array OS version? It’s a house of cards. I’ve seen entire infrastructures become unstable simply because a network card firmware was 3 months behind the one recommended by the array manufacturer.

The Bottleneck (The “I/O Blender Effect”)

This is a fascinating and destructive phenomenon. Imagine 50 VMs on a host.

  • VM 1 writes a large sequential file.
  • VM 2 reads from a database.
  • VM 3 boots up.

At the VM level, operations are clean. But when all these operations arrive at the same time in the storage controller funnel, they get mixed up. What was a nice sequential write becomes a slush of random writes (Random I/O). Traditional array controllers, originally designed for single physical servers, often collapse under this type of load, creating latency perceptible to the end user.

The Hidden Cost

Finally, 3-Tier is expensive. Very expensive.

  • Licensing & Support: You pay for server support, SAN switch support, and array support (often indexed to data volume!).
  • Footprint: As mentioned in the introduction, this equipment consumes enormous amounts of space and electricity.
  • Human Expertise: It often requires a team for compute, a team for network, and a team for storage. Incident resolution times explode (“It’s not the network, it’s storage!” – “No, it’s the hypervisor!”).
Cartoon of compute, network and storage teams blaming each other

Conclusion: A Necessary Foundation

The 3-Tier architecture is not dead. It remains relevant for very specific needs, like massive monolithic databases that require dedicated physical performance guarantees.

However, its management complexity and inability to scale linearly paved the way for a new approach. We started asking the forbidden question: “What if, instead of specializing hardware, we used standard servers and managed everything via software?”

It was this reflection that gave birth to Software-Defined Storage (SDS) and Hyperconvergence (HCI). But that is a topic for our next article.

Read More

Nutanix Technology Champion (NTC) 2026: A 3rd Star on the Jersey!

Published: 18 December 2025
Written by Julien D.
No comments
Categories: Lifestyle
Nutanix Technology Champion 2026

You might think that over time, you get used to it. That after two years, opening the email announcing the results becomes a mere administrative formality. Well, I must confess: not at all.

It is with immense pride – and undisguised relief – that I announce my nomination as a Nutanix Technology Champion (NTC) for the year 2026. This is the third consecutive year that I have the honor of joining this group of passionate experts.

Official announcement of the 2026 Nutanix Technology Champions

To be completely transparent, I never take this distinction for granted. In the IT world, technologies evolve fast, and so do we. Staying relevant requires work, curiosity, and above all, the desire to share. Seeing my name once again on the official NTC 2026 list is a beautiful validation of the efforts put into the blog throughout the year.

What is an “NTC”? (Spoiler: It’s not just a LinkedIn badge)

I am often asked if it is an exam I passed, like an NCP-MCI certification. The answer is no, and that is precisely the beauty of this program.

The Nutanix Technology Champion program does not just reward passing a technical multiple-choice quiz. It is a distinction that recognizes community engagement. Basically, Nutanix spots those who spend their free time testing, breaking, fixing, and above all explaining their technologies to others. Whether through blog posts (like here), forum contributions, or talks at events.

For the purists, it is the equivalent of the vExpert at VMware or the MVP at Microsoft. It is the validation of what we call technical “Soft Skills”: the ability to evangelize a solution not because we are paid to do so, but because we master its intricacies and we love it. It is a recognition by peers and by the vendor, and that is what makes it so rewarding.

Under the Hood: Why this nomination matters for the blog

Beyond the shiny logo to put in a signature, being an NTC has a direct impact on the quality of what I can offer you on juliendumur.fr. It is not an honorary title devoid of meaning; it is a key that opens interesting doors.

Concretely, this status gives me privileged access behind the scenes. I have the opportunity to exchange directly with Product Managers and Nutanix engineering teams. This means that when I write a technical article, I can validate my hypotheses at the source, avoiding approximations.

Furthermore, we have access to roadmap briefings and Beta versions. Even if this information is often under NDA (I can’t reveal everything to you in advance!), it allows me to understand the direction the technology is taking. I can thus better anticipate topics to cover and offer you more relevant analyses as soon as features reach General Availability (GA). It is the assurance for you to read content that is not only technically accurate but also in phase with market reality.

Retrospective and 2026 Goals: Full Steam Ahead

This third nomination is the fruit of consistency. But above all, it marks the beginning of a new year of “lab”. The goal is not to collect stars, but to continue exploring the Nutanix Cloud Platform from every angle.

For 2026, I intend to keep offering practical tutorials and field feedback. While the AHV hypervisor remains the unavoidable foundation, I really want to move up the software stack a bit more this year. Expect to see topics covering container orchestration with NKP (Nutanix Kubernetes Platform), automation, and probably a stronger focus on security with Flow. The objective remains the same: dissecting the tech to make it accessible.

A huge thank you to the community for the daily exchanges, and of course to the NTC program team (shout out to Angelo Luciani) for their renewed trust. It is a pleasure to be part of this virtual family.

Now, the ball is also in your court: are there specific topics or features of the Nutanix ecosystem that you would like to see me cover this year? The comments are open!

Read More

Nutanix AOS 7.5, AHV 11.0, and PC 7.5: Complete Breakdown of This Massive Update

Published: 10 December 2025
Written by Julien D.
1 Comment
Categories: Nutanix AHV EN, Nutanix EN
Nutanix AOS 7.5, AHV 11.0 and Prism Central 7.5

It’s one of those mornings where the coffee tastes a little different. The taste of major announcements that are bound to change our habits as administrators. Nutanix has just released a trio of major updates into the wild: AOS 7.5, AHV 11.0, and Prism Central 7.5.

Let’s be clear from the start: I’ve combed through the Release Notes for you, and this isn’t just a simple “Patch Tuesday.” It is a structural overhaul. Nutanix is no longer content with just improving its HCI; the vendor is breaking its own dogmas (hello external storage and compute-only nodes) and drastically tightening security, even if it shakes up our old reflexes.

While on paper, the promises of performance (AES everywhere) and flexibility (Elastic Storage) are enticing, my field experience dictates a certain prudence. When you mess with the storage engine and SSH access at the same time, you don’t rush into production without reading the fine print carefully. That is exactly what I’m proposing here: an unfiltered technical analysis of what awaits you.

AOS 7.5: Performance & Architecture

Let’s start with the core of the reactor: AOS 7.5. If you thought the Nutanix storage architecture was set in stone, think again. This version marks a turning point in hot data and disk space management.

The Key Concept: AES Becomes the Absolute Standard

Until now, the Autonomous Extent Store (AES) was often reserved for high-performance All-Flash environments. With 7.5, that’s over: AES becomes the default architecture for all deployments, whether All-Flash or Hybrid.

Why is this important? Because AES improves metadata locality and reduces CPU consumption for I/O. But be careful, the critical novelty here is the automatic migration. If you upgrade an existing hybrid cluster to 7.5, AOS will launch a background conversion task to switch to AES.

Do not underestimate the I/O impact of this “transparent” conversion. Even if Nutanix handles it in the background, metadata restructuring is never trivial on a loaded cluster. Furthermore, Nutanix introduces a revamped Garbage Collection (GC) (“Accelerated Data Reclamation”). It is now capable of cleaning multiple “holes” in an Erasure Coding stripe in a single pass and merging inefficient stripes. It’s brilliant for efficiency, but it confirms that the engine is working much more “intelligently” under the hood.

The Unexpected Opening: Pure Storage and Dense Nodes

This might be the strongest sign of this release: Nutanix is officially opening up to third-party storage. AOS 7.5 supports connecting to Pure Storage FlashArray arrays via NVMeoF/TCP for capacity storage. Nutanix handles the compute, Pure handles the data. For HCI purists like me, this is a paradigm shift, but one that meets a real need for disaggregation.

Finally, for those managing storage monsters, note that existing All-Flash nodes can be upgraded to support up to 185 TB per node, while maintaining aggressive RPOs (NearSync/Sync).

AHV 11.0 & Flexibility: The Era of “Compute-Only” and Elastic Storage

If AOS 7.5 boosts the engine, AHV 11.0 changes the bodywork. For a long time, Nutanix preached the dogma of strict hyperconvergence: “You buy identical nodes, you expand storage and compute at the same time.” With this version, I feel like Nutanix is finally listening to those who, like me, found themselves with too much CPU and not enough disk (or vice versa).

The Key Concept: Official Disaggregation

It’s a small revolution: Nutanix now allows the deployment of “Compute-Only” nodes much more flexibly. We are seeing the arrival of a standalone AHV installer. Concretely, you can manually install AHV via an ISO on a server, without going through the heaviness of a full re-imaging via Foundation.

For labs or rapid compute power expansions, this is a phenomenal time-saver. But be careful, this requires increased rigor regarding hardware compatibility management, as Foundation will no longer be there to act as a safeguard during installation.

The Awaited Feature: Elastic VM Storage

This is undoubtedly the feature I was waiting for the most to break down silos. With Elastic VM Storage, available starting with AHV 11.0 and AOS 7.5, you can finally share a storage container from one AHV cluster to another AHV cluster within the same Prism Central.

Imagine: your Cluster A is bursting at the seams storage-wise, but your Cluster B is sleeping half-empty. Before, you had to move VMs. Now, you can mount the container from Cluster B onto Cluster A and deploy your VMs directly on it.

It’s great, but caution. It’s not magic. You are introducing a critical network dependency between two clusters that were previously isolated. If your inter-cluster network fails, the VMs on Cluster A hosted on Cluster B go down. Moreover, Nutanix clearly states that this allows “serving storage from a remote cluster,” which necessarily implies additional network latency compared to native data locality. Reserve this for workloads that are not sensitive to disk latency or for temporary overflow.

Finally, note the arrival of Dual Stack IPv6. AHV can now talk to your DNS, NTP, and Syslog servers in IPv6. A necessary update to align with modern network standards.

Security and Governance: Locking Everything Down (SSH, vTPM, Profiles)

Let’s move on to the part that will make command-line regulars (myself included) grind their teeth. Nutanix has decided to tighten the screws on security, and they aren’t kidding around.

The Key Concept: The Digital Fortress

The goal is clear: reduce the attack surface, especially against ransomware that often attempts to propagate via lateral movements on management interfaces. Nutanix is therefore introducing mechanisms to limit direct human access to infrastructure components (CVM and Hosts).

The Critical Change: CVM Secure Access (The End of SSH is coming)

This is the number one vigilance point of this article. With AOS 7.5, you now have the option (and strong incentive) to totally disable SSH access to CVMs and AHV hosts.

On paper, this is excellent for security (“Security by Obscurity”). In operational reality, it is a violent cultural change. No more quick ssh nutanix@cvm to check a log or run a quick diagnostic script. Everything must go through APIs or the console.

Danger Warning! Before checking that “Disable SSH” box, check your migration procedures. The Release Notes are formal: disabling SSH breaks Cross-Cluster Live Migration (CCLM) workflows, whether in On-Demand mode (OD-CCLM) or Disaster Recovery (DR-CCLM). These operations still rely on SSH tunnels between source and destination hosts. If you cut SSH, your migrations will fail. You will have to re-enable SSH to make them work. This is a major operational constraint to anticipate.

Governance: vTPM & Guest Profiles

For highly sensitive environments, AHV now supports storing vTPM encryption keys in an external KMS. This allows centralizing key management and aligning the vTPM security policy with the cluster’s “Data-at-Rest” encryption policy.

On the quality of life side, I welcome the arrival of reusable Guest Customization Profiles. No more tedious copy-pasting of Sysprep scripts with every VM clone. You create a profile (Windows + NGT 4.5 min required), store it, and apply it on the fly to clones or templates. It’s simple, efficient, and avoids input errors.

Prism Central 7.5: The Interface That Makes Life Easier (NIM & Policies)

We finish this overview with Prism Central 7.5 (pc.7.5). If AOS is the engine and AHV the chassis, PC is the dashboard. And believe me, it is fleshing out considerably to save us from ungrateful manual tasks.

The Key Concept: Intelligent Orchestration

The major addition is the arrival of VM Startup Policies. This is a feature I’ve been waiting for for years to replace my cobbled-together startup scripts. Concretely, you can now define the exact restart order of VMs during an HA event (node failure) or a cluster restart.

This allows managing application dependencies cleanly: “Start the Database, wait for it to be UP, then start the Application Server”. It’s native, integrated into the interface, and greatly secures recovery plans.

For large-scale environments, note the appearance of NIM (Nutanix Infrastructure Manager). It is a new orchestrator designed to provision, configure, and manage your datacenters in a standardized way, aligning with the famous “Nutanix Validated Designs” (NVD). It is clearly oriented for very large deployments that want to avoid configuration drift.

Enhanced Resilience: PC Backup & Restore

Until now, restoring a crashed Prism Central could be an adventure, especially if the original cluster was itself down. Nutanix has lifted a major technical constraint: you can now recover a Prism Central instance from a backup located on any Prism Element cluster.

This is a detail that changes everything in case of a total site disaster. Previously, recovery from a Prism Element backup was restricted to the specific cluster where PC was registered. This new flexibility, coupled with the ability to backup to a generic S3 Object Store, makes the management architecture much more robust. We are no longer putting all our eggs in one basket.

Conclusion & Recommendations: Maturity Has a Price

After dissecting these three release notes, my feeling is clear: Nutanix is reaching an impressive level of maturity. The generalization of AES and the opening to external storage show that the platform is ready for the most demanding workloads and the most complex architectures.

However, as a “Prudent Ghost Writer,” I must raise a final red flag before you click “Upgrade.”

⚠️ Watch out for prerequisites: Do not rush headlong into the Prism Central update. Version pc.7.5 requires your Prism Element clusters to run at least AOS 7.0.1.9. If you are on an earlier version, deployment will be blocked. You will have to plan your migration path rigorously.

This is an unavoidable update for the performance and security gains, but it is also a structural update. The AES conversion, the potential SSH deactivation, and the new network dependencies for elastic storage require validating these changes in a pre-production environment.

Take the time to test, check your compatibility matrices, and above all, do not cut SSH before verifying that you do not have any planned inter-cluster migration (CCLM)!

To your keyboards, and happy upgrading!

Read More

Maxi Best of Nutanix CLI: checking VMs

Published: 28 October 2025
Written by Julien D.
No comments
Categories: Nutanix AHV EN, Nutanix EN
nutanix ahv cli reference guide

In this new blog post, we’ll cover all the main Nutanix AHV CLI commands that allow you to perform some checks on your virtual machines using the command line.

All the commands in this article can be run via SSH from any CVM in the cluster.

Display the list of virtual machines

To display the list of virtual machines on the Nutanix cluster, simply run the following command:

acli vm.list

This will show you all the VMs present on the cluster, without the CVMs:

nutanix@NTNX-S348084X9211699-B-CVM:192.168.84.22:~$ acli vm.list
VM name VM UUID
LINUX 88699c96-11a5-49ce-9d1d-ac6dfeff913d
NTNX-192-168-84-200-PCVM-1760699089 f659d248-9ece-4aa0-bb0c-22a3b3abbe12
vm_test 9439094a-7b6b-48ca-9821-a01310763886

As you can see, I only have two virtual machines on my cluster:

  • My Prism Central
  • A newly deployed “LINUX” virtual machine
  • A test virtual machine

A handy command to quickly retrieve all virtual machines and their respective UUIDs. Now let’s see how to retrieve information about a specific virtual machine.

Retrieving Virtual Machine Information

To display detailed information about a virtual machine, use the following command:

acli vm.get VM_NAME

Using the example of my “LINUX” virtual machine, this returns the following information:

nutanix@NTNX-S348084X9211699-B-CVM:192.168.84.22:~$ acli vm.get LINUX
LINUX {
config {
agent_vm: False
allow_live_migrate: True
apc_config {
apc_enabled: False
}
bios_uuid: "88699c96-11a5-49ce-9d1d-ac6dfeff913d"
boot {
boot_device_order: "kCdrom"
boot_device_order: "kDisk"
boot_device_order: "kNetwork"
hardware_virtualization: False
secure_boot: False
uefi_boot: True
}
cpu_hotplug_enabled: True
cpu_passthrough: False
disable_branding: False
disk_list {
addr {
bus: "ide"
index: 0
}
cdrom: True
device_uuid: "fae2ee55-8736-4f3a-9b2c-7d5f5770bf33"
empty: True
iso_type: "kOther"
}
disk_list {
addr {
bus: "scsi"
index: 0
}
cdrom: False
container_id: 4
container_uuid: "2ead3997-e915-4ee2-b9a4-0334889e434b"
device_uuid: "f9a8a84c-6937-4d01-bfd2-080271c44916"
naa_id: "naa.6506b8def195dc769b32f3fe47100297"
storage_vdisk_uuid: "215ba83c-44cb-4c41-bddc-1aa3a44d41c7"[7] 0:python3.9* "ntnx-s348084x9211699-" 21:12 21-Oct-25 vmdisk_size: 42949672960
vmdisk_uuid: "42a18a62-861a-497a-9d73-e959513ce709"
}
generation_uuid: "9c018794-a71a-45ae-aeca-d61c5dd6d11a"
gpu_console: False
hwclock_timezone: "UTC"
machine_type: "pc"
memory_mb: 8192
memory_overcommit: False
name: "LINUX"
ngt_enable_script_exec: False
ngt_fail_on_script_failure: False
nic_list {
connected: True
mac_addr: "50:6b:8d:fb:a1:4c"
network_name: "NUTANIX"
network_type: "kNativeNetwork"
network_uuid: "7d13d75c-5078-414f-a46a-90e3edc42907"
queues: 1
rx_queue_size: 256
type: "kNormalNic"
uuid: "c6f02560-b8e6-4eed-bc09-1675855dfc77"
vlan_mode: "kAccess"
}
num_cores_per_vcpu: 1
num_threads_per_core: 1
num_vcpus: 2
num_vnuma_nodes: 0
power_state_mechanism: "kHard"
scsi_controller_enabled: True
vcpu_hard_pin: False
vga_console: True
vm_type: "kGuestVM"
vtpm_config { is_enabled: False
}
} is_ngt_ipless_reserved_sp_ready: True
is_rf1_vm: False
logical_timestamp: 1
state: "kOff"
uuid: "88699c96-11a5-49ce-9d1d-ac6dfeff913d"

As you can see, this returns all the information about a virtual machine. It is possible to filter some of the information returned with certain commands. Here are the ones I use most often:

acli vm.disk_get VM_NAME : to retrieve detailed information of all disks of a virtual machine

nutanix@NTNX-S348084X9211699-B-CVM:192.168.84.22:~$ acli vm.disk_get LINUX
ide.0 {
addr {
bus: "ide"
index: 0
}
cdrom: True
device_uuid: fae2ee55-8736-4f3a-9b2c-7d5f5770bf33
empty: True
iso_type: "kOther"
}
scsi.0 {
addr {
bus: "scsi"
index: 0
}
cdrom: False
container_id: 4
container_uuid: "2ead3997-e915-4ee2-b9a4-0334889e434b"
device_uuid: f9a8a84c-6937-4d01-bfd2-080271c44916
naa_id: "naa.6506b8def195dc769b32f3fe47100297"
storage_vdisk_uuid: 215ba83c-44cb-4c41-bddc-1aa3a44d41c7
vmdisk_size: 42949672960
vmdisk_uuid: 42a18a62-861a-497a-9d73-e959513ce709
}

acli vm.nic_get VM_NAME : to retrieve the detailed list of network cards attached to a virtual machine

nutanix@NTNX-S348084X9211699-B-CVM:192.168.84.22:~$ acli vm.nic_get LINUX
50:6b:8d:fb:a1:4c {
connected: True
mac_addr: "50:6b:8d:fb:a1:4c"
network_name: "NUTANIX"
network_type: "kNativeNetwork"
network_uuid: "7d13d75c-5078-414f-a46a-90e3edc42907"
queues: 1
rx_queue_size: 256
type: "kNormalNic"
uuid: "c6f02560-b8e6-4eed-bc09-1675855dfc77"
vlan_mode: "kAccess"
}

acli vm.snapshot_list VM_NAME : to retrieve the list of snapshots associated with a virtual machine

nutanix@NTNX-S348084X9211699-B-CVM:192.168.84.22:~$ acli vm.snapshot_list LINUX
Snapshot name Snapshot UUID
SNAPSHOT_BEFORE_UPGRADE e7c1e84e-7087-42fd-9e9e-2b053f0d5714

You now know almost everything about verifying your virtual machines.

For the complete list of commands, I invite you to consult the official documentation: https://portal.nutanix.com/page/documents/details?targetId=Command-Ref-AOS-v7_3:man-ncli-c.html

In the next article, we’ll tackle a big task: creating virtual machines using CLI commands.

Read More

Nutanix on OVHcloud : connect your Palo Alto gateway to the RTvRack

Published: 20 October 2025
Written by Julien D.
No comments
Categories: Nutanix EN, Nutanix NC2 EN
Connecting a Palo Alto gateway to the OVHcloud RTvRack

In a previous article, we covered how to deploy and perform the basic configuration of a Palo Alto gateway to replace the basic gateway supplied with your OVHcloud Nutanix cluster.

I will now show you how to connect this gateway to the RTvRack supplied with your cluster to connect it to the internet.

Connecting the Gateway to the RTvRack

In “Network > Zones”, we start by creating a new “Layer3” zone, which we’ll call “WAN” for simplicity:

Creating the Layer3 WAN zone

You can also create one or more other zones to connect your other interfaces (e.g., an “INTERNAL” zone).

Next, in “Network > Interfaces,” edit the ethernet1/1 interface. If you’ve successfully created your VM on Nutanix, it will correspond to the WAN output interface. It will be a “Layer3” interface:

Layer3 ethernet1/1 interface in the WAN zone

On the “Config” tab, select the “default” Virtual Router and select the “WAN” security zone.

On the “IPv4” tab, add the available public IP address in the range provided to you by OVHcloud with your cluster, making sure to include a /32 mask at the end:

Public IPv4 address in /32 on ethernet1/1

You can find the network information for your public IP address on your OVHcloud account in “Hosted Private Cloud > Network > IP”:https://www.ovh.com/manager/#/dedicated/ip

Using the public IP address and its associated network mask, you can deduce:

The public IP address to assign to the WAN port of your gateway

The IP address of the WAN gateway

Example with the network 6.54.32.10/30:

Network address (not usable): 6.54.32.8
First address (public address of the PA-VM): 6.54.32.9
Last address: 6.54.32.10 (WAN gateway address)
Broadcast address: 6.54.32.11 (broadcast address)

Repeat the operation with the interface corresponding to the subnet of your Nutanix cluster, using the IP address of the gateway you specified when deploying your cluster.

However, make sure to set the mask corresponding to that of the network in which the interface is located as indicated in the documentation: https://docs.paloaltonetworks.com/pan-os/11-0/pan-os-networking-admin/configure-interfaces/layer-3-interfaces/configure-layer-3-interfaces#iddc65fa08-60b8-47b2-a695-2e546b4615e9.

In “Network > Virtual Routers”, edit the default router. You should find your “ethernet1/1” interface at a minimum, as well as any other interfaces you may have already configured:

Default Virtual Router with its interfaces

Then, in the “Static Routes” submenu, create a new route with a name that speaks to you, a destination of 0.0.0.0/0, select the “ethernet1/1” interface and as Next Hop the IP address of the public network gateway provided to you by OVHcloud:

Default static route to the OVHcloud gateway

Finally, go to the “Device > Setup > Services” tab and edit the “Service Route Configuration” option in “Services Features” to specify the output interface and the associated /32 IP address for some of the services:

PA-VM Service Route Configuration

The list of services to configure at a minimum is as follows:

  • DNS
  • External Dynamic Lists
  • NTP
  • Palo Alto Networks Services
  • URL Updates

You can validate and commit. Your PA-VM gateway is now communicating with the OVHcloud RTvRack. All that’s left is to finalize the configurations to secure the installation and create your firewall rules to allow your cluster to access the internet.

Read More