Not on AIX, apparently. Not officially, anyway.

So this week I ported it.

The JavaScript Ecosystem, On a Dare

I expected the Go side to be the tricky bit. AIX ppc64 is big-endian, unusual for Linux developers, and the kind of platform where syscall packages are held together by build tags and prayer. Instead, the fight started in the web UI.

Prometheus 3.x ships a modern React UI built with Vite, which uses Rollup, which — as of version 4 — rewrote its parser in Rust and distributes it as native binaries per platform. Their supported list includes Linux on ppc64le. It does not include AIX on ppc64. These are the same CPUs. Different operating system, and suddenly we're off the map.

The official workaround is a WebAssembly build of the parser. I tried it. The WASM parser encodes AST node types as little-endian integers in a shared buffer, and on a big-endian system, those get byte-swapped on read. The first error said Unknown node type: 1207959552. That's 0x48000000, which is 72 with three zero bytes padded on the wrong side. 72 is a perfectly reasonable node type if you read the bytes the other way around. I tried an older version of Rollup. It threw a different endianness bug — memory access out of bounds — but the root cause was the same.

This is where I accepted that modern JavaScript was not going to be built on AIX this week.

The Actual Plan

The thing is, Prometheus's UI is a build-time artifact. The runtime never touches Node. The JavaScript toolchain only exists long enough to produce a folder full of HTML, CSS, and JS, which the Go compiler then embeds into the binary.

So I built the UI on my Mac. Shipped the folder to AIX. Compiled the Go binary there with the assets already baked in. The binary is self-contained — no Node, no Rollup, no WASM, nothing from that world is on the production machine.

This is also, it turns out, what Prometheus's own PREBUILT_ASSETS_STATIC_DIR mechanism exists for. It's in their scripts. It's not in their documentation. You find it by reading compress_assets.sh at 10pm and muttering.

The Go Side, Which Was Also Fun

With the UI sorted, go build got further and then fell over in new and interesting ways:

• File locking needs platform-specific implementations. AIX wasn't in the list. I had a flock_aix.go from a previous porting adventure, so that one was quick.

• github.com/edsrzf/mmap-go — the memory-mapping library Prometheus uses to read compacted data blocks — supports Linux, Darwin, Windows, Plan 9, wasm, and Solaris. No AIX. Wrote a mmap_aix.go. Patched it into the module cache, then discovered Go's package metadata cache had decided mmap-go didn't have an AIX file and wouldn't reconsider. go clean -cache and onwards.

• Directory fsync. On Linux, calling fsync() on a directory flushes directory metadata to disk. On AIX, it returns EINVAL. AIX's JFS2 doesn't expose the operation through that syscall — the journaling filesystem handles metadata durability its own way. Prometheus's TSDB code calls directory fsync in five places. Each one needed guarding with runtime.GOOS != "aix".

I argued with the Prometheus team about that last one years ago. Didn't go anywhere. But the patches are mine now.

It works

After all that, the binary builds, starts, scrapes itself, serves the UI, writes data to disk, persists through restarts, compacts blocks, memory-maps them back in on query, handles snapshots, and generally behaves like Prometheus does everywhere else. I ran promtool tsdb analyze against a populated data directory — the heaviest exercise of the mmap path you can inflict on it short of production traffic — and it finished clean.

Why You Might Care

If you run AIX, you probably already have some combination of nmon, Tivoli, enterprise monitoring shit, and a pile of scripts doing monitoring. They work. They've worked for decades. Why add Prometheus?

A few reasons that might actually apply to you:

It's the same tooling as the Linux half of your environment. If your shop has AIX LPARs next to Linux VMs next to whatever-else, Prometheus is probably already monitoring the Linux side. Bringing AIX into the same dashboard, the same alert rules, the same query language — that's worth something. One Grafana, not two monitoring philosophies.

The query language is genuinely good. PromQL lets you ask questions like "show me the 95th percentile CPU usage across all my LPARs in the last week, aggregated by workload group" as a single line.

Everything speaks Prometheus. If you want to alert on AIX metrics into PagerDuty, Slack, Teams, ServiceNow, or a pigeon — Alertmanager already has an integration, or someone's written a webhook for it. That ecosystem didn't grow around AIX, but it works for AIX once you're emitting Prometheus metrics.

node_exporter on AIX already exists. See my last week's newsletter. Pair it with Prometheus-on-AIX, and you have a self-contained monitoring loop that doesn't require a Linux jump box to collect metrics from.

Common Europe Congress 2026 is there!

The agenda is published! Do you want to know where AIX is going to? It means you MUST visit the Common Europe Congress in Lyon, France. There will be sessions about new AIX features and open source community development. We will talk about AIX and IBM Power automation and Zero Downtime for AIX. Join me in Lyon!

Your turn

The binary is here: https://dl.power-devops.com/prometheus/prometheus-3.11.2.aix-ppc64.tar.gz

Unofficial. Not blessed by the Prometheus project. Built from upstream 3.11.2 with the AIX patches described above. If it eats your data, I'll be sympathetic but not liable.

Minimum-viable deployment:

mkdir -p /data
cd /opt
gzip -dc /tmp/prometheus-3.11.2.aix-ppc64.tar.gz | tar xf -
cd prometheus-3.11.2.aix-ppc64

cat > prometheus.yml <<'EOF'
global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']

  - job_name: 'node'
    static_configs:
      - targets: ['your-aix-host:9100']
EOF

./prometheus --config.file=prometheus.yml --storage.tsdb.path=/data/prometheus

Browse to http://your-prometheus-server:9090/, type up in the query box, and hit Execute. If you see 1, Prometheus is scraping itself, and you're in business.

To run it properly in the background, wire it into /etc/inittab. In the same way as I did it last week with node_exporter.

If you try the build, tell me how it breaks. It built and ran on my machine, which is not quite the same as saying it'll run on yours, and the only way this port becomes actually reliable is if enough people poke at it to shake out the weird cases.

Share

Have fun with Prometheus on AIX!

Andrey

Hi, I am Andrey Klyachkin, IBM Champion and IBM AIX Community Advocate. This means I don’t work for IBM. Over the last twenty years, I have worked with many different IBM Power customers all over the world, both on-premise and in the cloud. I specialize in automating IBM Power infrastructures, making them even more robust and agile. I co-authored several IBM Redbooks and IBM Power certifications. I am an active Red Hat Certified Engineer and Instructor.

Follow me on LinkedIn, Twitter and YouTube.

You can meet me at events like IBM TechXchange, the Common Europe Congress, and GSE Germany’s IBM Power Working Group sessions.

What could I answer? Yup, thanks for your birthday wishes! ;-)

Prometheus

No, it was not about the titan from Greek mythology, who helped people to steal fire from the gods.

It is about Prometheus monitoring software, which was started many years ago by SoundCloud, and is now a part of the Cloud Native Computing Foundation (CNCF). Prometheus is very popular in different clouds. It is easy to deploy, and paired with Grafana, it makes monitoring very visual and democratic.

No, Prometheus does not run on AIX.

If you wish to try an older version of Prometheus on AIX, you can do it. Several years ago, I ported some Prometheus versions to AIX, which you could find on my power-devops.com site. But the site doesn’t work right now.

The patches to the Prometheus code were not accepted because AIX is missing some functions available on Linux, and without these functions, Prometheus can’t guarantee that the data was written to the disk.

But Prometheus was available for Linux on IBM Power (ppc64le) for years.

Node Exporter

Prometheus works with so-called exporters that are installed on target servers.

The exporters are small HTTP (or HTTPS) servers that provide metrics - data about the target server.

Prometheus collects information from those exporters - or scrapes them.

There are exporters for specific services, and there are exporters for the operating system - node exporters.

Of course, it was not a big problem to compile the standard node exporter for AIX. I did it almost the same time, I ported Prometheus to AIX. But the node exporter didn’t collect any useful information about AIX.

This was the reason to start developing Google Go interface to AIX libperfstat. It is available freely on Github - https://github.com/power-devops/perfstat/.

I also tried to develop my own AIX node exporter, but never published it.

But now there is an official AIX node exporter from the Prometheus Team!

How to get the AIX node exporter

It is very easy!

• Open the node exporter Github repo

• On the right side, find “Releases” and click the latest release

• Now you should see the latest release and assets for it

• Click node_exporter-1.11.1.aix-ppc64.tar.gz (or what is the latest release when you read it) and download the file.

The archive contains only three files:

• LICENSE

• NOTICE

• node_exporter

What you need is the last file. You can copy it to the target system and run it there. There are no dependencies and no installation.

How to run the AIX node exporter

The easiest way to run it is simply to start it.

After you started it, it listens on port 9100, and you can check if it is working by using curl:

curl http://localhost:9100/metrics

You will get a long list with different metrics.

You don’t need any special knowledge to get through the list and check which metrics are delivered by the node exporter.

Of course, you don’t want to start the node exporter every time manually. You can simply add it to /etc/inittab like:

mkitab 'node_exporter:23456789:once:/usr/bin/node_exporter >/dev/console 2>&1

Now it starts every time with the system.

Common Europe Congress 2026 is there!

The agenda is published! Do you want to know where AIX is going to? It means you MUST visit the Common Europe Congress in Lyon, France. There will be sessions about new AIX features and open source community development. We will talk about AIX and IBM Power automation and Zero Downtime for AIX. Join me in Lyon!

Do you have any ideas how to make it better?

I didn’t do any thorough tests of the new node exporter. I only started it on AIX 7.3 TL3 and checked if it works.

It will definitely not work on POWER7. Because it is compiled with Google Go, and the Google Go compiler supports only POWER8 or newer CPUs.

It will probably not work on AIX 7.1, 6.1, or 5.3. I don’t have any AIX 5.3 to test, but if I have time, I will test it with AIX 6.1 or 7.1.

It probably doesn’t have all the metrics you need. It definitely has fewer metrics if you compare it to njmon.

If you have any ideas on what can be done better or any suggestions for metrics, let me know! Simply answer to the newsletter, if you’ve got it by email, or write a comment down. I will check and make a patch to enable the metric you need.

Share

Have fun with the AIX node exporter!

Andrey

Hi, I am Andrey Klyachkin, IBM Champion and IBM AIX Community Advocate. This means I don’t work for IBM. Over the last twenty years, I have worked with many different IBM Power customers all over the world, both on-premise and in the cloud. I specialize in automating IBM Power infrastructures, making them even more robust and agile. I co-authored several IBM Redbooks and IBM Power certifications. I am an active Red Hat Certified Engineer and Instructor.

Follow me on LinkedIn, Twitter and YouTube.

You can meet me at events like IBM TechXchange, the Common Europe Congress, and GSE Germany’s IBM Power Working Group sessions.

Read more

But there are some problems with Terraform and IBM Power.

First, it doesn’t run on IBM Power. You can download it for the x86 CPUs for almost every operating system. You can download it for ARM64 CPUs for Linux. You can even download it for Solaris. But you can’t find it for Linux on IBM Power (ppc64le) or for AIX.

OK, I ported it several times in the past, and you can find an older version of Terraform on my site.

But we have the second problem. Terraform works with plugins. Terraform itself is a configuration language plus a runner for the plugins. The plugins do the work.

No, there are no Terraform plugins to deploy an LPAR on IBM Power.

Or better to say, there was no Terraform plugin till today.

I think Friday the 13th is a good date to publish something new.

Let me introduce…

Terraform provider for IBM Power HMC

Here it is. You need Terraform for x86_64 (yes, no Power support right now), an IBM Power HMC, and the plugin. Then you write some code and deploy an LPAR.

What can it look like?

terraform {
  required_providers {
    ibmpower = {
      source  = "registry.terraform.io/power-devops/hmc"
      version = "0.0.1"
    }
    dns = {
      source = "hashicorp/dns"
    }
  }
}

variable "hmc_host" {
  description = "HMC hostname or IP address"
  type        = string
}

variable "hmc_username" {
  description = "HMC username"
  type        = string
}

variable "hmc_password" {
  description = "HMC password"
  type        = string
  sensitive   = true
}

variable "system_name" {
  description = "Managed system name where the LPAR will be created"
  type        = string
}

variable "lpar_name" {
  description = "Name of the LPAR to create"
  type        = string
  default     = "test-lpar"
}

provider "ibmpower" {
  host     = var.hmc_host
  username = var.hmc_username
  password = var.hmc_password
  insecure = true
}

data "ibmpower_vios_list" "all" {
  system_name = var.system_name
  sort = true
}

resource "ibmpower_lpar" "example" {
  system_name = var.system_name
  name        = var.lpar_name

  desired_mem = 8192
  desired_procs = 2
  sharing_mode    = "uncap"
  max_virtual_slots = 20
  boot_mode         = "norm"

  virtual_eth_adapters = [
    {
      is_required = true
      port_vlan_id = 1
    }
  ]

  virtual_fc_adapters = [
    {
       remote_lpar_id = data.ibmpower_vios_list.all.vios[0].lpar_id
       remote_slot_number = data.ibmpower_vios_list.all.vios[0].next_virtual_slot
       is_required = true
       physical_fcs = "fcs0"
    },
    {
       remote_lpar_id = data.ibmpower_vios_list.all.vios[1].lpar_id
       remote_slot_number = data.ibmpower_vios_list.all.vios[1].next_virtual_slot
       is_required = true
       physical_fcs = "fcs1"
    }
  ]
}

resource "ibmpower_lpar_action" "example_install" {
  system_name = ibmpower_lpar.example.system_name
  name = ibmpower_lpar.example.name
  action = "netboot"
  wait_for_state = "Running"
  timeout = 900
  netboot_server_ip   = "10.10.2.4"
  netboot_gateway_ip  = "10.10.2.1"
  netboot_client_ip   = "10.10.2.20"
  netboot_subnet_mask = "255.255.255.0"
}

resource "terraform_data" "wait_for_boot" {
  depends_on = [ibmpower_lpar_action.example_install]

  provisioner "local-exec" {
    command = <<-EOT
      for i in $(seq 1 120); do
        ssh -o ConnectTimeout=5 -o StrictHostKeyChecking=no ${var.lpar_name} "echo ready" 2>/dev/null && exit 0
        echo "Waiting for ${var.lpar_name}... ($i/120)"
        sleep 30
      done
      echo "Timeout waiting for ${var.lpar_name}"
      exit 1
    EOT
  }
}

What does it all mean?

If you have never worked with Terraform, you can check the Terraform tutorials to learn the basics of Terraform’s language.

If you worked with Terraform before and know how to use it, you will find the documentation for the plugin in the plugin’s package.

BUT. There is one gotcha with the plugin. It is not published on the official Terraform registry, and no, I don’t have plans to publish it there.

If you want to use it, use the link to download it directly.

You must create a file called terraformrc for your project with the following contents:

provider_installation {
  dev_overrides {
    "registry.terraform.io/power-devops/hmc" = "/home/myuser/dir-with-the-plugin"
  }
  direct {}
}

and export the environment variable:

export TF_CLI_CONFIG_FILE=/home/myuser/path/to/terraformrc

Then you can start terraform apply and the LPAR will be created.

But… I use NIM, and before I install an LPAR, I must create a NIM definition

So what? Let me introduce my second Terraform plugin.

Terraform provider for IBM AIX NIM

Yes, I use NIM too. I must also create a NIM definition for each AIX LPAR and assign resources to it.

Even more, I want to configure my NIM server using Terraform.

Now it is possible!

The NIM plugin is also available for download.

The same conditions apply. The documentation is in the archive.

You can add something like this to the previous code:

terraform {
  required_providers {
    ibmpower = {
      source  = "registry.terraform.io/power-devops/hmc"
      version = "0.0.1"
    }
    nim = {
      source  = "registry.terraform.io/power-devops/nim"
      version = "0.0.1"
    }
    dns = {
      source = "hashicorp/dns"
    }
  }
}

variable "nim_host" {
  description = "NIM hostname or IP address"
  type        = string
}

variable "nim_username" {
  description = "NIM username"
  type        = string
}

variable "nim_pkey_path" {
  description = "Path to the user's private key"
  type        = string
  sensitive   = true
}

provider "nim" {
  host             = var.nim_host
  username         = var.nim_username
  use_agent        = true
}

data "dns_a_record_set" "nim" {
  host = var.nim_host
}

resource "nim_standalone" "example" {
  name = ibmpower_lpar.example.name
  ssl = true
}

resource "nim_bos_inst" "example" {
  standalone = nim_standalone.example.name
  lpp_source = "7300-03-01-2520-lpp_source"
  spot = "7300-03-01-2520-spot"
  resolv_conf = "resolv_conf_default"
  bosinst_data = "bosinst_data_default"
  image_data = "image_data_default"
  fb_script = "fb_rootkeys"
}

resource "ibmpower_lpar_action" "example_install" {
  depends_on = [nim_bos_inst.example]
  system_name = ibmpower_lpar.example.system_name
  name = ibmpower_lpar.example.name
  action = "netboot"
  wait_for_state = "Running"
  timeout = 900
  netboot_server_ip   = "10.10.2.4"
  netboot_gateway_ip  = "10.10.2.1"
  netboot_client_ip   = "10.10.2.20"
  netboot_subnet_mask = "255.255.255.0"
}

Or if you wish to configure a new NIM server:

resource "nim_bosinst_data" "bos" {
  name = "bosinst_data_default"
  content = file("${path.module}/files/bosinst_data_default")
  destination = "/nim/rsrc/bosinst_data_default"
}

resource "nim_image_data" "img" {
  name = "image_data_default"
  content = file("${path.module}/files/image_data_default")
  destination = "/nim/rsrc/image_data_default"
}

resource "nim_resolv_conf" "resolv_conf_default" {
  name = "resolv_conf_default"
  content = file("${path.module}/files/resolv_conf_default")
  destination = "/nim/rsrc/resolv_conf_default"
}

resource "nim_script" "nim_pwreset" {
  name = "pwreset"
  content = file("${path.module}/files/pwreset.sh")
  destination = "/nim/scripts/pwreset"
}

resource "nim_script" "nim_authkeys" {
  name = "authkeys"
  content = file("${path.module}/files/authkeys.sh")
  destination = "/nim/scripts/authkeys"
}

resource "nim_fb_script" "nim_fbscript" {
  name = "fb_rootkeys"
  content = file("${path.module}/files/fb_rootkeys.sh")
  destination = "/nim/scripts/fb_rootkeys"
}

resource "nim_lpp_source" "_7300-03-01-2520-lpp_source" {
  name = "7300-03-01-2520-lpp_source"
  location = "/nim/lpp/7300-03-01-2520-lpp_source"
  source = "/nim/dist/AIX_v7.3_Install_7300-03-01-2520_flash_122025_LCD8265308.iso"
  iso_fs_type = "udfs"
}

resource "nim_spot" "_7300-03-01-2520-spot" {
  name = "7300-03-01-2520-spot"
  location = "/nim/spot"
  source = nim_lpp_source._7300-03-01-2520-lpp_source.name
}

Support the Power DevOps Newsletter!

If you like reading technical articles about IBM Power, AIX, and Linux on IBM Power, consider upgrading to the paid tier to show your support. As a paid subscriber, you not only get regular posts, but you will get additional posts with the full code and further explanations, access to the whole archive of the blog, and take part in our monthly calls where you can ask your questions and propose topics for future newsletters. Be an active member of our community!

Some final words

These are beta version software. You can use it for free, but there is no guarantee that it works in your environment. And of course, no liability. The providers provided “AS IS”.

The providers work with both Terraform and OpenTofu, the free implementation of Terraform.

If you have any problems using them, feel free to drop an email to me. Simply answer the newsletter, and the email should come to me. I will check if I can help you and answer as soon as I can do it.

If you need official support, do the same. Write an email to me, and we will discuss what I can do for you.

Because this is beta software and I am actively developing it, the archives can be updated without any notice. The version can be the same, but the providers will be different ;-)

No, I don’t plan to make the source code available.

No, I don’t know if the providers will always be freely available.

It always depends on how many customers I have and how many of them are interested in these plugins.

Anyway, you can download the plugins right now and use them! If you have downloaded them, nobody can take them away from your computer.

Share

Have fun deploying LPARs with Terraform!

Andrey

Hi, I am Andrey Klyachkin, IBM Champion and IBM AIX Community Advocate. This means I don’t work for IBM. Over the last twenty years, I have worked with many different IBM Power customers all over the world, both on-premise and in the cloud. I specialize in automating IBM Power infrastructures, making them even more robust and agile. I co-authored several IBM Redbooks and IBM Power certifications. I am an active Red Hat Certified Engineer and Instructor.

Follow me on LinkedIn, Twitter and YouTube.

You can meet me at events like IBM TechXchange, the Common Europe Congress, and GSE Germany’s IBM Power Working Group sessions.

Read more

Read more

Read more

Registration of NIM clients

Read more

Read more

Yes, nothing.

This is exactly my point. We are too few. I must know that you need what I write.

The playbook

Read more

Read more

Read more

But last week I wrote about image.data NIM resource, and I didn’t have enough space to post the whole file together with my explanations. I do it today.

image.data

Read more

Read more

Read more

Read more

As for me, 2025 was like a roller coaster. It had so many events, and they were so different, that I can’t even say which one was the best during the yea…

Read more

Read more

Read more

Read more