Team Leader - Nutanix Technology Champion - Nutanix NTC Storyteller

Julien DUMUR
Infrastructure in a Nutshell

Author: Julien D.

Lost IPMI Password on a Nutanix or Supermicro Node: The Recovery Guide

Published: 10 August 2026
Written by Julien D.
No comments
Categories: Nutanix AHV EN, Nutanix EN, Tech and Lab

A little misadventure happened to me recently. After changing the IPMI password on my 1-node, I couldn’t log back into my node’s management interface. Forgot it instantly? Typo? Botched copy-paste? Whatever the reason, the access lockout was very real.

Losing your IPMI password (or BMC) is enough to make anyone break a sweat. But rest assured, experience has taught me a golden rule: as long as you still have access to the host operating system (whether it’s AHV, a standard Linux, or even ESXi), you can regain control without needing to perform a hardware reset.

However, the situation can be more critical than it seems. For the experts reading this, you know that in a Nutanix Single-Node environment, IPMI isn’t just an administrative convenience: it’s your one and only fail-safe. Without it, you can’t mount a Phoenix ISO via Remote Media during a major AOS crash or force a reboot. Losing BMC access on such a node quickly becomes a critical bottleneck for your production and remote console access.

In this guide, I’ll share the different methods to regain control of your node in a matter of minutes, from the gentlest approach to the last resort.

Method 1: In-band Reset via ipmitool

If you are running Nutanix AHV or a classic Linux distribution, you’re in luck: the ipmitool utility is usually available natively. The trick here relies on the KCS (Keyboard Controller Style) hardware channel. Simply put, this allows the host OS to communicate directly with the BMC chip via the motherboard bus (LPC/PCIe), entirely bypassing the management network.

Identify and Overwrite the Admin Account

Log in as root on your host. As a precaution, first ensure that the kernel modules managing IPMI are loaded:

modprobe ipmi_si
modprobe ipmi_devintf

Next, we’ll list the configured users (usually on channel 1) to spot the ID of our administrator account. In 99% of cases, the default account (ADMIN) corresponds to ID 2.

ipmitool user list 1

In my case, the ID is indeed 2:

Once the ID is confirmed, the command to force a new password is child’s play:

ipmitool user set password 2 'MyNewPwd123!'

When entering the previous command, the terminal might throw a nasty Invalid data field in request error.

Don’t panic; it’s simply the security policy parser of some firmwares rejecting your request. Not only does it require a minimum complexity (8 characters, uppercase, lowercase, number), but it can also be picky about the request format.

To bypass (or rather, satisfy) this mechanism, force the encoding length to 20 bytes by simply appending 20 to the end of your command:

ipmitool user set password 2 'MyNewPwd123!' 20

Your password has now been overwritten. You can test the connection to the web interface.

Method 2: The IPMICFG Utility (The Solution for VMware ESXi)

If you are running VMware ESXi, the first method might leave you stranded. Why? Because ipmitool is not packaged natively, and resolving dependencies to compile it on a hypervisor is a waste of time that I wouldn’t recommend.

The workaround is called IPMICFG. This is the official tool provided by Supermicro (downloadable from their portal with a free account). Its massive advantage is that it comes as static binaries, ready to use for Linux, Windows, and crucially, ESXi.

Once the archive is transferred to your host and extracted, using it is very straightforward:

./IPMICFG-Linux.x86_64 -user list
./IPMICFG-Linux.x86_64 -user setpwd 2 MyNewPwd123!

Note: Adapt the binary name if you are using the Windows or ESXi version.

You can download the utility here: https://www.supermicro.com/wdl/utility/IPMICFG/

Extreme Case: The Node No Longer Has a Bootable OS

What if the OS won’t boot at all? This is usually where the sweating starts, thinking that without network access to the IPMI or a functional OS, the only remaining option is a factory reset.

Remember: the KCS interface is exposed at the hardware level as soon as the BIOS POST completes. It is completely independent of your storage’s state.

All you have to do is boot the server from a USB stick containing a Linux Live CD (Ubuntu, Rocky Linux). Once on the live desktop, open a terminal, install the utility if it isn’t already there (e.g., apt install ipmitool), and run the exact same commands from Method 1.

Last Resort Method: The BMC Factory Reset

If for some obscure reason the previous methods fail, there is one ultimate resort left: resetting to factory settings.

With the Supermicro tool, the command is direct:

./IPMICFG-Linux.x86_64 -fd

And if you prefer the pure ipmitool method, you need to send a RAW command:

ipmitool raw 0x3c 0x40

⚠️ Warning, the consequences are heavy: Your entire BMC configuration is wiped clean. You will lose the static IP (the port reverts to DHCP), VLAN configurations, and user accounts. The BMC will then reboot (expect a good 2 to 3 minutes). Pay close attention to recent generations of servers: the password may not revert back to ADMIN/ADMIN. It defaults to the unique password printed on the OCP label (often stuck on the chassis or motherboard). Keep this in mind if your server is physically located on the other side of the world!

My Recommendations

Once access is recovered via method 1 or 2, here is what I systematically do to cover my back:

  1. The Password Manager: It’s basic, but save your creds immediately instead of keeping them in your copy-paste clipboard.
  2. The Backup Account: Create a second administrator account.
  3. The Slot ID Trick: Do not put your backup account on Slot ID 3. Force its creation on a higher Slot (like 5 or 6). Why? Because some infrastructure automation scripts have the annoying tendency to forcefully overwrite or modify the early Slots (2 and 3) during provisioning. By placing it further down, you safeguard it.

What about you? Have you ever locked yourself out of one of your nodes? Share your worst nightmare in the comments below!

Read More

Nutanix AHV: Mastering VM Startup Policies

Published: 23 July 2026
Written by Julien D.
No comments
Categories: Nutanix AHV EN, Nutanix EN

A few years ago, following a power outage at one of our two sites, I had to deal with some application issues after the Nutanix cluster restarted. On paper, everything should have gone smoothly: the UPS had taken over, causing no impact on production, but that was without counting on a mishandling by the technician who turned off the UPS. The cluster shut down abruptly.

Once the power returned, the cluster restarted automatically, and all the VMs restarted shortly after. The problem was that some database servers took their time… Too much time for certain business applications…

It’s exactly to save you from these late-night cold sweats that we are going to explore VM Startup Policies on Nutanix AHV today.

While the concept of sequencing the startup of your servers might seem simple, the underlying mechanics are worth a closer look.

What are “VM Startup Policies”?

VM Startup Policies are a native feature of the AHV hypervisor that acts as a scheduler when powering on your virtual machines. This feature was added with version 7.5, which I talked about a while ago on the blog.

Instead of suffering the startup order and leaving control to the cluster, you define precise groups of VMs and strict dependency rules. This way, you guarantee that your infrastructure services (like an Active Directory, for example) and your databases are fully operational before allowing the application servers to start.

To fully understand the importance of these rules, a quick reminder of Acropolis HA’s default behavior is necessary. In the absence of a Startup Policy, during a node crash or a cluster restart, the restart of VMs is done in best-effort mode. The Prism Element cluster focuses on rapid resource allocation (CPU/RAM) and triggers the power-on of VMs completely asynchronously and concurrently, and natively has no awareness of your application dependencies.

When do these rules really activate?

It is important to clarify that these strategies do not apply if you decide to restart a VM manually from the Prism Central interface in the middle of the day.

AHV orchestration wakes up and applies your Startup Policies in two critical scenarios:

  1. A High Availability (HA) event: One or more physical nodes in your cluster fail. The AHV hypervisor will migrate and restart the affected VMs on the surviving nodes, strictly respecting the order you defined.
  2. A Full Cluster Restart: Exactly the case of my anecdote! Following a total power outage, for example.

Decrypting the Mechanics: The 3 Fundamental Pillars

Nutanix’s approach has the merit of being extremely visual and very easy to grasp from Prism Central. It relies on three fundamental concepts.

1. Categories

Nutanix’s mechanics rely exclusively on Prism Central Categories. You don’t link “SQL-Server-01” to “Web-Server-01”, but you link the AppMetier:Database category, for example, to the VMs hosting databases and your application VMs to the AppMetier:Applicatif category.

This is where the true power of this architecture lies. If tomorrow you deploy three new application servers in scale-out to handle an unexpected load, you just need to assign them the right category. They will automatically be integrated into the correct order of your Startup Policy without you having to open or modify a single rule.

2. Dependency Levels

This is how you draw your logical chain: category B can only start if category A has finished. There is still a small subtlety to keep in mind: Nutanix allows a maximum of 6 consecutive dependency levels per policy. In 99% of cases, this is more than enough for a classic application (e.g., Infra > DB > Web), but it requires grouping your services well without micromanagement.

3. Start Conditions

That’s the million-dollar question: how does the AHV hypervisor know that the database is really ready to authorize the next step? The tool offers you 2 options:

  • VM Power On: As soon as the VM is powered on at the hardware level, the next step is launched. The Windows or Linux OS is not even loaded yet. To be avoided for strong dependencies.
  • Guest Boot up: The best of the best! Nutanix waits patiently for the OS to be fully loaded and the network layer to respond.

For the “Guest Boot up” condition to work, the Nutanix Guest Tools (NGT) must absolutely be installed and up to date on the VM. My advice (and the vendor’s recommendation): do not skip the NGT deployment!

There is also an option that complements either one:

  • Delay (in seconds): We “blindly” wait a given time (e.g., 60 seconds) before moving on.

Tutorial: Creating a Startup Policy

Let’s model the most common example: we want to start our domain controllers, wait for them to be ready, start our databases, and finally our application servers.

For this occasion, I created 3 categories: AppType:ActiveDirectory, AppMetier:Database, and finally AppMetier:Applicatif

  1. Log in to Prism Central.
  2. Go to the Infrastructure > Compute > VMs > Policies > VM Startup Policies menu.
  3. Click on Create VM Startup Policy.
  4. Give it an explicit name (e.g., Policy-Tiering-Metier).
  5. In the visual interface, add your first category (e.g., AppType:ActiveDirectory).
  6. Add a second block for AppMetier:Database and a third for AppMetier:Applicatif.
  7. Click on + Configure Start Conditions to define the startup conditions. Choose Guest Boot up and optionally add a 30-second safety delay to allow the internal OS services time to initialize properly.

Click on “Create”, and you’re done!

All that’s left is to add your VMs to the right categories.

Pitfalls to Avoid

The tool is great, but here is some field feedback to help you avoid falling into certain traps:

1. Manage the 6-Level Limit Intelligently

Don’t fall into the micromanagement trap! If you try to make a policy for every micro-application, you will quickly saturate the interface, reach the famous 6-level limit, and end up with a convoluted system that’s impossible to maintain over time. Group your resources intelligently and keep it simple!

2. Beware of the Interaction with DR Mechanisms

Startup Policies manage the local resilience of a cluster (HA or reboot). But beware, if you use Nutanix Disaster Recovery to failover to a remote site, this system has its own recovery plan mechanism. During an inter-site failover, it’s the Prism Central Recovery Plan that takes control of the startup order, and no longer your local Startup Policy. Therefore, ensure logical consistency between the two tools.

3. This Only Applies to Guest VMs

There is no need to try sequencing “Nutanix” VMs (Prism Central, CVM, or others…), it will not work. The mechanism is only applicable to your virtual machines, not system ones.

Conclusion

VM Startup Policies on Nutanix AHV are the kind of feature you configure once, forget about, and which can save precious time and provide peace of mind the day the unthinkable happens. Thanks to an intuitive visual interface based on categories, Nutanix has made application resilience accessible to everyone.

If you haven’t already done so, I strongly encourage you to check the status of your NGT (deployment status and versions) and categorize your most critical VMs today. Your future “you,” woken up at 3 AM during the next production incident, will thank you!

Read More

Install Claude Code on WSL : The complete guide for VS Code

Published: 16 July 2026
Written by Julien D.
No comments
Categories: AI, Tech and Lab, Windows

As many of you know, my raw development level oscillates somewhere between absolute zero and “it miraculously started working”.

But now, the game has changed. Artificial intelligence, and more specifically CLI (Command Line Interface) coding agents like Claude Code, have given me superpowers. Suddenly, coding is no longer an insurmountable mountain, but a conversation. However, there’s a catch: to converse with the machine, your environment needs to be rock solid. And developing on Windows, historically, was a bit like trying to fit a square peg into a round hole.

Fortunately, WSL (Windows Subsystem for Linux) is here. The idea behind this guide? To save you from the cold sweats I experienced. I’m going to show you how to set up a clean Ubuntu environment on Windows, pack it with the necessary dependencies (Cargo, npm), install Claude Code, and connect it all seamlessly to Visual Studio Code.

Why bother with WSL2, you might ask? Quite simply because it allows us to completely isolate our AI tools. Claude Code will run in its own Linux sandbox, with native I/O performance, all completely independent of our Windows system. We keep full control.

Ready to transform your Windows machine into an AI-boosted development station? Follow the guide, I’ve cleared the minefield for you.

1. Enable and install WSL (Windows Subsystem for Linux)

Let’s not lie to ourselves: there was a time when installing a Linux environment on Windows was a real obstacle course. You had to dig into obscure menus, check “Windows Features”, and pray very hard. Today, Microsoft has caught up, and it all comes down to a single command line.

Installing WSL

Start by opening PowerShell as an administrator (right-click on the Start menu > Windows PowerShell (Admin) or Terminal (Administrator)).

Simply type this command and press Enter:

wsl --install

Let the magic happen. Once it’s finished, the golden rule of IT applies: restart your PC. This isn’t optional; Windows needs this reboot to activate the virtualization components at the system level.

WSL: Choosing your distribution

Upon reboot, WSL is there, but we’re going to make sure we install the right distribution. Reopen PowerShell (no need for admin rights this time).

To see what’s available in the “catalog”, type:

wsl --list --online

In our case, we’re going with the absolute standard, Ubuntu. That’s where the community is largest, and where you’ll find the most solutions if you ever run into an error message.

Launch the installation with:

wsl --install Ubuntu

A terminal window will open, asking you to create a UNIX username and a password.

Why does WSL2 change everything? For the more curious, you should know that this command enables WSL2 by default. This detail is crucial. Gone is the first version (WSL1) where Windows clumsily tried to translate Linux commands on the fly. Today, WSL2 uses a genuine, ultra-lightweight virtual machine (based on Hyper-V) with a real Linux kernel optimized by Microsoft. The result? 100% compatibility with development tools and blazing-fast file access (I/O) performance, which will be vital for Claude Code to read our code quickly.

2. Prepare the Ubuntu environment

Alright, the Linux distribution is installed, but a brand-new Linux system is like an empty apartment: it’s very clean, but you can’t do much in it.

Before bringing in our AI super-agent, we need to bring in the furniture, or rather the dependencies. Many modern CLI tools rely on very specific ecosystems.

Install Cargo (and our first AI tool)

For my own experiments, I often use the Rust ecosystem. So we’re going to install its package manager, cargo.

Type this into your Ubuntu terminal:

sudo apt install cargo

Why Cargo? Because it will allow us to install tools directly from their source code. For example, I use rtk, a highly practical AI framework. To install it, it’s as simple as this:

cargo install --git https://github.com/rtk-ai/rtk

Let it compile. It’s beautiful to watch (even if, I admit, I often watch these dozens of compilation lines scroll by like a deer in the headlights, just praying there won’t be any flashing red text at the end).

What is RTK for, you might ask? Well, it saves Claude Code tokens through automations, allowing us to chat longer with Anthropic’s AI to preserve our quotas.

Install Node.js and npm

Next, Claude Code and many other agents use web technologies. Therefore, we need npm (Node Package Manager).

Run the command:

sudo apt install npm

If a bearded and/or bald senior developer is reading this tutorial, he’s going to choke: “Ju, you never install npm via apt, it installs an old version and creates permission errors!”. And he would probably be right. The “real” best practice is to use NVM (Node Version Manager). However, let’s be pragmatic: for our specific goal of running Claude Code CLI today, the stable version provided by the Ubuntu repositories does the job perfectly. If, later on, you start racking up EACCES type errors when installing other global packages, you’ll know it’s time to clean it all up and switch to NVM!

3. Install and configure Claude Code

The official installation script

To install Claude Code, Anthropic made things simple. Well, “simple” in a Linux way. We’re going to use a tool called curl which will download a script from their servers and execute it directly on our machine.

Type this into your Ubuntu terminal:

curl -fsSL https://claude.ai/install.sh | bash

Normally, tossing an unknown script found on the net directly into your machine’s bash is the digital equivalent of picking up a USB drive on the sidewalk and plugging it straight into your PC. But hey, this is Anthropic, we’ll assume they don’t want to mine bitcoin on our backs.

The script will do its thing for a bit. And then, full of hope, eyes shining, you type claude in your terminal. And bam… claude: command not found.

Frustration. Cold sweats. Don’t panic, it’s a classic trap.

The infamous PATH trap

Why doesn’t it work on the first try?

Because Anthropic does things properly by respecting the principle of least privilege. Instead of brutally installing Claude Code at the root of your system (which would require super-administrator root rights and could break everything), the script places the executable in a neat little hidden folder of your own: ~/.local/bin.

The problem is that your Ubuntu system doesn’t look in this specific folder by default when you run a command. You have to explicitly show it the path. This is what we call the $PATH environment variable.

To fix this once and for all, we’re going to add this famous folder to our PATH. Copy and paste this line (be careful, copy it exactly with its quotes):

echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc && source ~/.bashrc

This double command does two things: it writes the correct path at the end of your personal configuration file (.bashrc), and it asks the terminal to re-read this file immediately to apply the change (source).

Now, type claude or claude --version again. If a menu or a version number appears: you’ve won!

4. Final integration with VS Code

It’s all well and good to have the Claude CLI running quietly in a terminal on WSL, but the idea is still to have it read and write code comfortably. And for that, we need our trusty Visual Studio Code.

The WSL extension for VS Code

Open VS Code normally, on Windows. Go to the extensions tab and search for WSL (formerly Remote – WSL, published directly by Microsoft). Install it.

Once installed, look at the very bottom left of the VS Code window. You will see a small blue (or green) icon with >< chevrons. Click on it, and choose the “Connect to WSL” option.

A new VS Code window will open. In the bottom left corner, it now says “WSL: Ubuntu”. Bingo.

This is where the power of the architecture I mentioned earlier hits hard. When you open a project this way, VS Code installs a mini-server directly inside your Linux machine. The graphical interface (the editor) runs on Windows, but all the development logic, the integrated terminal, and file access run natively on Ubuntu.

The Claude plugin for VS Code

Having the CLI to run global commands is great, but let’s be honest: having Claude integrated directly into the editor’s interface is the ultimate comfort.

Still in this new VS Code window (connected to WSL), go back to the extensions tab and search for the official Claude extension (or Claude Dev/Cline depending on your preference).

⚠️ Warning: VS Code now manages two distinct “zones” of extensions. Those installed on your local Windows, and those installed inside your WSL machine. Make sure to click on the small blue button “Install in WSL: Ubuntu” if VS Code prompts you.

If you mistakenly install it on the Windows side, the plugin will spin its wheels and will be completely unable to read your Linux project files or understand the commands you send it.

Once the plugin is activated on the Ubuntu side, a new icon will appear in your sidebar. There you are, with the powerful CLI in the terminal below, and the responsive visual assistant on the side. A real control tower!

Conclusion

And there you have it, full circle. In a few command lines, we’ve gone from a walled-off Windows environment to an ultra-high-performance hybrid setup. You now have a clean Ubuntu subsystem, ready to compile Rust, run Node, and above all, host your new AI assistant.

For my part, with my “weekend dev” level, this setup has changed my life. I discuss, I guide, I supervise, and Claude manages the code. How about you, what will be your first project with this new stack?

Read More

Nutanix Tech Connect 2026: My exclusive invitation to the heart of Nutanix HQ

Published: 13 July 2026
Written by Julien D.
No comments
Categories: Events, Tech and Lab
Nutanix Tech Connect 2026

Some emails are simply more exciting to receive than others. When I saw that famous “You’re in” pop up in my inbox, I got a little rush of adrenaline. I am thrilled to share with you my invitation to the highly exclusive Nutanix Tech Connect 2026, taking place this coming October 26 and 27 right at headquarters, at Nutanix HQ in San Jose in the Silicon Valley!

As you know, on a daily basis, I spend a good part of my days with my nose deep in the Nutanix ecosystem at Inetum. It’s my playground. But this trip is the opportunity to literally step through the looking glass. And for the 2nd time! (see my article recounting my 2 days at NTC Tech Connect 2024).

If massive tech gatherings like the .NEXT event are perfect for discovering public announcements surrounded by thousands of attendees, Tech Connect is its exact opposite. It’s behind the scenes. Only a select few, hand-picked from the most active members of the NTC (Nutanix Technology Champions) community, are invited. And we are not making the trip to listen to the usual marketing pitch, but to dive right into the thick of it, exchange under NDA (Non-Disclosure Agreement), and dissect the architecture with the people who build the platform.

What is the Nutanix Tech Connect?

A gathering of enthusiasts

Being part of the NTC program already means evolving every day within an incredible community of sharing and mutual aid. But this in-person event takes the concept even further. It was designed as an intimate gathering. Nutanix’s goal here is not to fill a convention center, but to bring together around a table a handful of enthusiasts whose voices and field experience truly matter.

Direct impact on the Nutanix roadmap

This is where we hit the ultimate goal for any systems engineer! During these two days of immersion in San Jose, we leave the sales presentations at the door. Our direct contacts? Product Management (PM) and the Research & Development (R&D) teams.

It’s a golden opportunity to transparently discuss the evolution of the AOS (Acropolis Operating System) foundation and the future capabilities of our AHV hypervisor. It is precisely during these “unfiltered” roundtables that we dissect the complex use cases we encounter on our production clusters. Knowing that our “pain points” and field feedback can directly influence the technical roadmap and shape the code for upcoming releases is simply exhilarating!

On the agenda: Two days of immersion in San Jose

The program for these two days promises to be dense. The invitation email is clear: the goal is to interact directly with engineering, product teams, and even Nutanix executives. In practical terms, this translates into interactive technical sessions where we will be able to “challenge” architectural choices. It’s the perfect time to ask those pointed questions that often go unanswered on traditional forums, and above all, to get an exclusive sneak peek (strictly under NDA!) at what is brewing in the vendor’s labs.

The other huge asset of Tech Connect is networking. Gathering physically with NTCs from all four corners of the globe is a guarantee of incredibly rich exchanges due to the diverse backgrounds of all attendees. We compare our infrastructures, share our feedback, and often find solutions to complex problems over a simple cup of coffee. This synergy among passionate experts is what makes the true strength of the Nutanix community.

Between now and the end of October, preparations will ramp up. In the coming weeks, we’ll be treated to an exclusive “Kickoff” webinar to discover the detailed agenda, planned sessions, and, hopefully, a few surprises. Then comes the time to secure flights and accommodations.

For my part, the technical preparation has already begun! I am actively compiling my notes, my observations on the latest versions of AOS, and most importantly, feedback from colleagues. Because yes, I fully intend to be the spokesperson for our French-speaking community at this event!

Thank you and see you in California!

While waiting for October, I am going to quietly start putting together my compilation of notes and observations and work on some stickers to swap with my fellow NTCs. You can count on me to give you a detailed report when I return (at least, on everything that won’t be protected by the NDA!).

To conclude, I wanted to extend a huge and sincere thank you to Angelo, as well as to all the Nutanix teams, for this exceptional opportunity and for organizing this event. The recognition from this community is a powerful driving force on a daily basis.

See you in San Jose!

Read More

OpenClaw on Nutanix AHV: The Complete Prerequisites Guide

Published: 9 July 2026
Written by Julien D.
No comments
Categories: AI, Nutanix AHV EN, Nutanix EN, Tech and Lab

In a previous article, we saw how to deploy OpenClaw on Nutanix AHV. However, before you can fully enjoy this autonomous AI agent, it is crucial to prepare the ground. OpenClaw is not just a simple script: it’s an ecosystem that relies on several technological building blocks to “think” (local LLM), “execute” (Node.js) and “search” (SearXNG).

In this article, we are going to detail the step-by-step installation of all the necessary prerequisites on your virtual machine (running Ubuntu), explaining for each one why it is essential for OpenClaw to work properly.

1. NVIDIA Drivers: Unleashing GPU Power

OpenClaw can rely on large language models (LLMs) running locally. While it is technically possible to run these models on a processor (CPU), performance would be extremely slow. Installing NVIDIA drivers allows the system to leverage the graphics card (GPU) allocated to your VM via Nutanix AHV (vGPU or Passthrough), thereby ensuring fast and smooth AI inference.

Here is how to update your system and install the appropriate drivers:

# System update
sudo apt update && sudo apt upgrade -y

# NVIDIA server driver installation
sudo apt install nvidia-driver-535-server -y

# Reboot required to take effect
sudo reboot

After the reboot, check that your GPU is correctly recognized with the following command:

nvidia-smi

2. Node.js (v24): OpenClaw’s Execution Engine

The core logic of OpenClaw is developed in JavaScript/TypeScript. Node.js is the execution environment that allows running the agent’s code, managing its dependencies, and orchestrating calls between the interface, the AI model, and the various tools. We are targeting version 24.x here to ensure optimal compatibility.

# Adding the NodeSource repository and installing
curl -fsSL [https://deb.nodesource.com/setup_24.x](https://deb.nodesource.com/setup_24.x) | sudo -E bash -
sudo apt install -y nodejs

# Verifying the installed version
node --version  # should display v24.x

3. Ollama & Qwen 2.5: The Local Brain of the Operation

Ollama is the tool that will allow us to easily download and run our AI model locally. For OpenClaw, we are going to use the Qwen2.5 (7B) model. Why this choice? It’s a lightweight model (suitable for GPUs with about 8 GB of VRAM) and, above all, it is excellent at “Tool Calling”. It is this capability that allows OpenClaw to understand that it needs to execute a web search or run a script rather than simply generating text.

# Installing Ollama
curl -fsSL [https://ollama.ai/install.sh](https://ollama.ai/install.sh) | sh

# Start the Ollama service (in the background)
ollama serve &

# In another terminal, verify that Ollama detects the GPU:
nvidia-smi  # You should see ollama in the list of GPU processes

# Pull (download) the recommended model
ollama pull qwen2.5:7b

# Test the model and verify its execution on the GPU
ollama run qwen2.5:7b "say hello"

# While the model is generating a response, check VRAM usage
nvidia-smi

4. Docker: The Containerization Infrastructure

In order to extend OpenClaw’s capabilities (especially for web search which we will see next), we need third-party services. Docker allows these services to be deployed in an isolated, standardized, and fast manner, without polluting our host system with multiple complex dependencies.

# Installing initial dependencies
sudo apt update
sudo apt install -y ca-certificates curl gnupg

# Adding Docker's official GPG key
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL [https://download.docker.com/linux/ubuntu/gpg](https://download.docker.com/linux/ubuntu/gpg) | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

# Configuring the Docker repository
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \
  [https://download.docker.com/linux/ubuntu](https://download.docker.com/linux/ubuntu) \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# Installing Docker packages
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

# Adding your user to the docker group to avoid using 'sudo' every time
sudo usermod -aG docker $USER
newgrp docker

# Verifying the installation
docker --version

5. SearXNG: Giving AI Access to the Web

For OpenClaw to be a truly performant search agent, it cannot rely solely on the data contained in the Qwen model (which stops at its training date). SearXNG is a privacy-respecting metasearch engine. By installing it via Docker, we provide OpenClaw with an API (on port 8080) that it can use to retrieve real-time information from the web and source its answers.

# Create a dedicated directory for configuration
mkdir -p ~/searxng && cd ~/searxng

# Run the SearXNG container
docker run -d \
  --name searxng \
  --restart unless-stopped \
  -p 8080:8080 \
  searxng/searxng

# Verify that the container is running correctly
docker ps

# Test that the SearXNG API is responding
curl http://localhost:8080

6. Homebrew & GCC: The Compilation Tools

The OpenClaw Node.js ecosystem sometimes relies on low-level libraries or native packages that need to be compiled directly on your machine during installation. Homebrew (the well-known package manager on macOS, also very handy on Linux) and the GCC compiler are essential to avoid errors during the final dependency installation phase (the famous npm install).

# Install the base Ubuntu compilation package
sudo apt-get install build-essential

# Install Homebrew
/bin/bash -c "$(curl -fsSL [https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh](https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh))"

# The end-of-installation instructions for Homebrew will ask you
# to add Homebrew to your PATH. Generally, it looks like this:
# (Make sure to adapt the path if necessary)
echo 'eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"' >> /home/$USER/.bashrc
eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"

# Install GCC via Homebrew
brew install gcc

Conclusion

Your virtual machine on Nutanix AHV is now a rich and complete environment, equipped with high-performance GPU drivers, an execution engine (Node.js), an LLM ready to answer (Ollama), web access (SearXNG), and the right compilation tools.

The groundwork is perfectly laid. All that’s left is for you to finalize the installation of the application itself by following the rest of our guide on OpenClaw.

Read More

Nutanix AHV : Deploy Nutanix Guest Tools on Rocky Linux 10

Published: 7 July 2026
Written by Julien D.
No comments
Categories: Nutanix AHV EN, Nutanix EN
header nutanix

A few months ago, I wrote an article about installing NGTs via the command line on Linux.

Having recently switched to Rocky Linux 10 for my lab VMs, I’ve run into a problem: the procedure I’ve been using doesn’t work!

Here’s how to work around the problem…

Installing Nutanix Guest Tools

Connect to your Nutanix cluster on Prism Central, go to the list of virtual machines, right-click on the virtual machine where you want to install NGT, and click “Install NGT”:

On the next screen, in my case there’s no need to change anything, click on “Confirm and Enter Password”:

Do not touch anything on this screen, simply click on “Skip and Mount” in the bottom left corner:

The ISO is mounted; now we move on to the command lines!

Installing Nutanix Guest Tools

Here are the commands to run on the virtual machine to install Nutanix Guest Tools:

  • System update:
sudo dnf update -y && sudo dnf upgrade -y
  • Install Python (if not already installed):
sudo dnf install python3
  • Verify drive letter ID:
blkid -L NUTANIX_TOOLS
  • Command output:
/dev/sr0
  • Mount the ISO:
sudo mount /dev/sr0 /mnt
  • Enter root mode:
sudo su
  • Install NGTs:
dnf install /mnt/installer/linux/ngt_rpm_installer/ngt_repo/nutanix-guest-agent-4.5.1-1.x86_64.rpm

  • Checking of the installation via command line:
yum list installed | grep 'nutanix-guest-agent'

On Prism Central side :

Read More

Urgency and budget: Why I 3D printed my own drive adapters

Published: 3 April 2026
Written by Julien D.
No comments
Categories: Lifestyle, Tech and Lab

We’ve all experienced that moment of loneliness in our professional careers. The one where you’ve planned the perfect hardware upgrade for your infrastructure, but a trivial detail disrupts the whole operation. Recently, we had to replace the 3.5-inch mechanical drives in one of our 4-node clusters with 2.5-inch SSD drives. A classic maintenance operation to move from hybrid storage to full-flash and gain some IOPS.

The only problem, and a big one: the original server caddies weren’t compatible with this smaller form factor.

First approach: “official” adapters

The obvious solution when managing a pro infra? Order official adapters or replacement caddies. We needed 24 pieces in total (6 drives for each of the 4 nodes). And then, reality hit hard.

Over 500 euros (including taxes and shipping).

But the worst part wasn’t actually the price: it was the lead time. Waiting several weeks when the project had to move forward? Unthinkable. Since I refused to pay this tax and wait, my 3D printer was going to take care of it.

Plan B: the DIY solution

The advantage of having standard hardware like Supermicro is that you’re never the first to encounter a problem. No need to spend hours on Fusion 360 modeling the part to the nearest millimeter: the open-source community has probably already done it.

In a few clicks on 3D model sharing platforms (like Printables or Thingiverse), I found the perfect .stl file : https://www.thingiverse.com/thing:4353094

To ensure compatibility, I quickly printed one to validate the dimensions and make sure it did the job…

The next step: industrialization. I positioned my models so I could print 6 adapters at once. This meant leaving the printer running for about 7.5 hours for each build plate.

On my Creality CR-10S Pro v2 running Klipper, I was able to monitor the print job to ensure everything went as planned out of the corner of my eye while continuing to work on my projects.

Despite a slight hiccup during the first batch that forced me to do a bit of mechanical tweaking, the prints went perfectly well.

Maker Spirit for the Win!

The final verdict is clear:

  • Vendor Option: ~€543 and a 3-week wait.
  • Maker Option: €20 of filament, a few kWh, and two solid days of printing.

Beyond the obvious financial savings (for the price of the official adapters, we could have bought the printer + the filament), the real lesson of this adventure is that the maker mindset allows you to transform a budgetary and temporal problem into a DIY solution that is 20 times cheaper and gets the job done in ultra-short timeframes.

So, the next time a problem rears its head, think “out-of-the-box” and, if need be, whip out your finest spool of filament.

Read More

The End of SSH on Nutanix: An Inevitable Shift to APIs

Published: 17 March 2026
Written by Julien D.
No comments
Categories: Nutanix AHV EN, Nutanix EN

Those who’ve been following the blog for a while surely remember my “Maxi Best-Of Nutanix CLI” series. I loved writing it, and obviously, it saved the day for some of you more than once. But with the announced end of SSH connections on Nutanix clusters, the days of firing up PuTTY to SSH into a CVM (Controller VM) and typing our ncli or acli commands as we please are over. Today, with the rise of Zero Trust architectures and STIG (Security Technical Implementation Guides) compliance requirements from the US DoD, locking down low-level access is no longer a paranoid option: it’s the production standard.

Why is the API becoming the only master on board?

Let’s be very clear: the REST API is the admin’s essential new Swiss Army knife.

It started with the progressive hardening of our infrastructures, notably with cluster lockdown, but the sentence officially fell in late January 2026: Nutanix announced the End of Support Life (EOSL) for “Bash Shell Access”. The reason is obvious. Leaving direct, unrestricted Bash access to the underlying OS (whether on AOS, AHV, or even Prism Central) has become absolute nonsense when it comes to guaranteeing security, auditability, and long-term support.

Here is the timeline I found in this document:

  • Under AOS 7.0 to 7.5, we started seeing login warnings, the appearance of an info alert warning of the deactivation of SSH password authentication, and options to disable SSH manually.
  • Starting from the next major NCI release, Bash will be disabled by default. Instead: an ultra-restricted “SSH Service Menu” allowing you to run a few acli/ncli commands to perform basic troubleshooting / actions.
  • And for late 2026? The “SSH Service Menu” is in place, the bash shell is disabled, but can be reactivated in “Support-Only” mode via a temporary token provided when handling a ticket with Nutanix support.

The only official, tracked, and complete entry point to interact with the infrastructure via command line is now the API.

Whether it’s the Prism Element API (v2.0) on an isolated cluster, or the Prism Central API (v3/v4) for multi-cluster management, there’s no escaping it: you have to dive in.

The API toolkit

Before we can blast our clusters with API requests, we need to gear up.

Daily, I switch between two go-to tools: Curl when I have a Linux/WSL terminal at hand (fast, raw, scriptable), and Postman when I need to visually explore Nutanix APIs.

If your workstation isn’t ready yet, I’ll point you directly to the dedicated article I’ve already written on this topic: Configure your Windows PC to query Nutanix APIs (WSL & Postman).

However, even when well-equipped, I regularly see admins tearing their hair out over their first Prism Element requests because of two crucial details.

The SSL certificate: By default, a Prism Element cluster uses a self-signed certificate. If you send a standard request, it will be violently rejected. The field reflex? Always add the -k (or --insecure) flag in your curl commands, and remember to disable the SSL certificate verification option in Postman settings.

Authentication: The Prism Element v2.0 API relies on Basic Auth. Avoid passing your credentials in plain text in the URL of your request (like https://admin:MySuperPass@IP...). It inevitably ends up in plain text in the history or logs. In Postman, use environment variables!

Exploring the API with the built-in REST API Explorer

How many times have you banged your head against the wall looking for the right syntax in a 500-page PDF documentation? With Nutanix, forget about that. The best documentation isn’t on the support portal; it’s directly embedded in your cluster.

Prism Element natively integrates an interface called REST API Explorer. To access it, it’s very easy: log in to your cluster’s web interface, click on your username at the top right, then select REST API Explorer. You can also type the URL directly: https://<CVM_IP>:9440/api/nutanix/v2/api_explorer/index.html.

The true power of this Swagger isn’t just listing the endpoints (GET /cluster, POST /vms…). It’s its ability to code for you! Fill in the required fields in the interface and click the “Try it out!” button. Not only does the interface execute the request and display the raw JSON response, but above all, it generates the complete and perfectly formatted curl command. It’s the ultimate hack to save time and avoid syntax errors.

Conclusion

I won’t hide it from you, moving from CLI to REST API took a little effort to adapt. At first, I fumbled around, I grumbled at a malformed header or a temperamental JSON. But once you’ve crossed that milestone, it becomes almost natural. The API opens the doors to large-scale automation and continuous integration. However, you unfortunately won’t be able to find equivalents for every single CLI command…

In the next article of this series, we’re going to get to the heart of the matter. Enough theory, we’ll tackle practice with our first concrete use case: The complete health check of a cluster.

Read More

OpenClaw on Nutanix AHV: Basic Installation Guide

Published: 16 March 2026
Written by Julien D.
No comments
Categories: AI, Nutanix AHV EN, Nutanix EN, Tech and Lab
openclaw on nutanix ahv

If you read my previous article detailing the architecture and the technical stack I chose to deploy OpenClaw, you already know why I decided to run this solution on my Nutanix AHV cluster. Today, we’re getting practical! I will show you, step by step, how to deploy your own instance on a freshly installed Ubuntu virtual machine.

Before kicking off the hostilities, here is a quick reminder of my setup. I provisioned a VM on Nutanix AHV with:

  • 8 vCPUs
  • 32 GB of RAM
  • 250 GB of storage
  • an NVIDIA Tesla P4 graphics card in PCI Passthrough

💡 Why favor full Passthrough over vGPU (virtual GPU)? Quite simply to guarantee near “bare-metal” inference performance. By giving our VM direct and exclusive access to the physical hardware, we completely eliminate the overhead (latency) associated with the virtualization layer.

Let’s start the deployment.

Preparing the Ubuntu VM: System and NVIDIA Drivers

The very first step is to prepare the ground to deploy our AI.

Ubuntu 24.04: Operating System Update

This is a rule I apply every single time I deploy a new operating system. As soon as I connect via SSH, I make sure all packages are up to date to avoid future security flaws or dependency conflicts.

sudo apt update && sudo apt upgrade -y

GPU: Installing NVIDIA Drivers

For OpenClaw to harness the computing power of my Tesla P4, the operating system must be able to communicate with it properly. Here are the commands to run to install the drivers (you can access a more detailed guide on the blog):

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

Once the machine has rebooted, we log back in and type the command to verify that our GPU is properly detected and ready to work:

nvidia-smi

Node.js and OpenClaw

Installing Node.js 22

OpenClaw is built on Node.js. To ensure we have a recent and efficient runtime environment (here version 22), we add the official NodeSource repository before launching the installation:

curl -fsSL [https://deb.nodesource.com/setup_22.x](https://deb.nodesource.com/setup_22.x) | sudo -E bash -
sudo apt install -y nodejs

Basic OpenClaw Deployment

Now that NodeJS is in place, we move on to installing OpenClaw. A simple curl script provided by the developers does the heavy lifting:

curl -fsSL [https://openclaw.ai/install.sh](https://openclaw.ai/install.sh) | bash

Once the installation is complete, the system automatically launches the configuration wizard for your instance. I will detail this step as well as the creation of API keys (Discord, Telegram, etc.) in a future blog post.

A small manipulation is required right after the OpenClaw installation if we want to be able to use “openclaw” commands without constraints. We need to add the local installation directory to our PATH environment variable (remember to adapt the username if you are not using administrateur):

export PATH="/home/administrateur/.npm-global/bin:$PATH"

💡 Why this manipulation? It’s an excellent security practice that I highly recommend. By exporting the PATH to ~/.npm-global/bin, we avoid installing global NPM packages with root (sudo) privileges. This significantly reduces attack surfaces and saves you from the eternal Linux permission conflicts!

Cleanly Exposing OpenClaw with Caddy

By default, the OpenClaw web interface listens on port 18789. Instead of attacking this port directly, I always prefer to place a reverse proxy in front of my applications. For this lab, my choice fell on Caddy.

sudo apt install -y caddy

💡 Why Caddy rather than Apache or Nginx? Because Caddy is formidably efficient. Where Nginx sometimes requires long configuration blocks for simple proxying, Caddy does the same job in literally three lines of code, all while being ultra-lightweight.

We edit its configuration file:

sudo vi /etc/caddy/Caddyfile

And we replace the entire content with the following instructions (replace the IP with the one of your VM, in my case 192.168.84.134):

192.168.84.134 {
    reverse_proxy 127.0.0.1:18789
}

Now, all that’s left is to restart the service so the proxy takes over:

sudo systemctl restart caddy

Network Security: Locking Down the OpenClaw Instance

Having a functional instance is good, securing it is essential. Even if you are on your local network (LAN), you should never leave open access to your control interface. We are going to apply a strict configuration via the OpenClaw CLI commands.

We start by restricting the Gateway listening to the local loopback to prevent any direct access:

openclaw config set gateway.bind loopback

We then force the operating mode to local, and activate token authentication (the bare minimum):

openclaw config set gateway.mode local
openclaw config set gateway.auth.mode token

Finally, since we are going through Caddy, we must authorize Cross-Origin requests (CORS) coming from our IP address, otherwise the browser will block the page (don’t forget to adapt the IP):

openclaw config set gateway.controlUi.allowedOrigins '["[https://192.168.84.134](https://192.168.84.134)"]'

We restart the service to apply our lockdown:

openclaw gateway restart

💡 The security pattern applied here is akin to local “Zero Trust”. By forcing OpenClaw on the loopback (127.0.0.1), we ensure that absolutely all traffic is forced to go through our Caddy proxy. Coupled with CORS filtering and authentication, we provide a baseline protection for our instance against potential scans or malicious scripts on the network.

First Contact and Configuration Validation

Retrieving the Access Token

Now that the doors are locked, we need the key. The authentication token was automatically generated during installation. We’re going to go fish it directly out of the JSON configuration file:

grep -i token ~/.openclaw/openclaw.json

Carefully copy this string of characters. Then open your browser and access your Web interface (e.g., https://192.168.84.134).

Enter the token in the “Gateway Token” box.

Device Approval

Once connected, you will notice that something is missing: the system is waiting for us to approve the “device” (the PC or tablet from which we wish to use OpenClaw) to grant it the right to process requests.

Return to your terminal to list the pending devices:

openclaw devices list

Locate your device ID in the list (a UUID-type string) and approve it:

openclaw devices approve b7beb7fa-fa4e-46e9-aec1-282bcce881f6

💡 Device approval (devices approve) is much more than a simple interface formality. It’s a sort of cryptographic handshake. This mechanism guarantees that no unsolicited machine can attach itself to your OpenClaw cluster instance without your knowledge!

Interaction Tests

The OpenClaw instance is now 100% operational! To validate our entire stack, there’s nothing like a full-scale test. You can send a first prompt on the web interface’s integrated chat, or configure a bridge to send a message on the Discord side.

Conclusion

We went from a simple Ubuntu VM to a true secured inference server, powered by Node.js and accelerated by a dedicated NVIDIA Tesla P4 GPU via Nutanix AHV. The architecture is clean, secured behind a Caddy proxy, and ready to handle our requests.

But this is only the beginning. In upcoming articles, we will go even further: I will show you how to configure OpenClaw via the startup wizard, deploy local models via Ollama, create an interactive Discord bot, and even inject Google API keys to equip our AI with search capabilities. Stay tuned!

Read More

OpenClaw on Nutanix AHV: Architecture and Tech Stack

Published: 13 March 2026
Written by Julien D.
No comments
Categories: AI, Nutanix AHV EN, Nutanix EN, Tech and Lab

If you follow my ramblings on the blog, you know I love tinkering with my clusters and testing somewhat out-of-the-box stuff (cf. my Steamdeck articles for example). Recently, I had a thought: Gemini or Claude in the public cloud is great for coding a Python script or writing emails. But when it comes to asking it to interact with our local infrastructure, that’s where it gets stuck.

So I wondered how I could connect artificial intelligence closer to my VMs. With this in mind, I got my hands on OpenClaw. Honestly, it was a bit of an obstacle course at the start. No more simple conversational gadgets, here we are talking about deploying a true Private AI on a Nutanix AHV cluster capable of acting on our infrastructure. Let me present the tech stack I chose for this experiment.

What is OpenClaw?

For those who have been living in a cave these past few months, OpenClaw is a GitHub project that exceeded 300k stars in just a few months. Imagine an ultra-intelligent thought translator coupled with a butler. Instead of clicking through dozens of menus in a complex interface, you simply ask your infrastructure to work for you in natural language (via a universal web interface or even messaging apps like WhatsApp and Telegram). It is even capable of working on its own while you sleep!

But where it gets exciting for us engineers is under the hood. OpenClaw is not just another “stateless” Large Language Model (LLM) that forgets everything with each new request. It is a true Agentic Gateway. Concretely, this means it orchestrates autonomous agents equipped with tools. These agents can be configured to tap directly into our cluster’s private APIs (like the REST APIs of Prism Element or Prism Central), code, browse the web, and synthesize certain information. In short, we don’t just ask the AI questions anymore, we delegate tasks to it.

Why Self-hosted?

In the field, the question of data governance arises the second the word “AI” is pronounced. Out of the question to send sensitive information to servers over which I have no control!

Choosing the Self-hosted route with OpenClaw means taking back absolute control. Data flows, execution logs, and API credentials stay locked down warm and safe on my network, isolated from the internet if desired.

Architecture and Tech Stack

For this project, a simple “Next, Next, Finish” on the corner of a table was out of the question. Here is the robust technical architecture I ended up validating for my deployment.

The Foundation: Nutanix AHV & Ubuntu 24.04 LTS

To run this beast, you need solid foundations. I provisioned a virtual machine running Ubuntu 24.04 LTS hosted directly on my Nutanix AHV cluster.

On the sizing side, I went with 8 vCPUs, 32 GB of RAM, and 250 GB of dedicated storage. You might tell me: “32 GB for a gateway, isn’t that a bit too much?” The gateway will have to ingest substantial data streams, maintain the cache of the various active agents, and potentially handle heavy parallel API querying. And besides, I can allocate these resources in my lab, so why deprive myself?

The Application Engine: NodeJS 22

At the heart of OpenClaw, the magic happens thanks to NodeJS 22. It is the execution engine that runs the gateway and its AI agent integrations.

Why is Node 22 an excellent architectural choice here? For its asynchronous management (Event Loop). When you ask OpenClaw to do a status report on 50 VMs, the gateway will initiate multiple API calls to Prism Central while keeping your WebSocket stream open to reply in real-time in the chat interface. NodeJS excels in this non-blocking concurrency management.

Network Routing: Caddy

The usual operating mode for OpenClaw is to deploy it locally on the machine from which you will connect to it, or to set up a tunnel to access the remote instance. Let’s not lie to ourselves, I wanted to type the IP in my browser and be able to access my instance, whether I’m on my PC or my tablet.

To make this possible, I use a Caddy Reverse Proxy. Caddy manages traffic routing and HTTPS encryption fully automatically.

I can already hear you saying: “Yes, but if a guy connects to your local network, he will have access to your instance!”. Well no! Because OpenClaw natively integrates a Device Whitelisting system. If your PC has never been connected to the instance, you will have to provide the “Gateway Token”. Then, you will have to accept this new connection on the OpenClaw instance side. As you can see, only previously authorized devices can enjoy your local instance.

The Entry Point: Discord

The choice of entry point, which will allow you to interact with OpenClaw, is often a matter of taste and colors.

OpenClaw directly integrates a chat system so you can talk to it. It’s good, it’s native, but inaccessible if I’m not at home. The system also offers to configure external entry points like Telegram, WhatsApp, Discord, or even Teams and Slack. And that is clearly a big plus because it gives almost unlimited possibilities!

What’s Next?

The goal of this article was to present the architecture envisioned for my OpenClaw assistant, to understand what we are deploying and why. We therefore have a coherent technical stack, performant thanks to Nutanix AHV, and hosted locally.

In a future article, I will explain how to install OpenClaw step by step until you have a functional instance.

Read More