The Go 1.25.9 toolchain runs natively on IBM i 7.5. node_exporter runs on top of it and emits real Prometheus metrics. And — as a side effect that turned out to be more useful than the goal — there's now a db2isql you can drop into ~/bin and use as a PASE replacement for STRSQL in green screen. All three are downloadable today.

If you want the short version: scroll to the bottom. If you want to know which IBM i quirks tried to kill me and lost, read on.

The Pile Of Patches

When I started, I promised myself I would not fork Go. I would maintain a re-baseable patch series against upstream, so that when Go 1.26 ships, I run git rebase, fix whatever the upstream Go team broke for me this time, and move on.

That promise survived contact with reality. The series sits at 42 patches against go1.25.9. The number is a coincidence. It is also, I am told, the answer to life, the universe, and everything, which feels appropriate for a Go port to a platform that does its own thing about most of life, the universe, and everything. All 42 apply cleanly. Each one does exactly one thing and has a commit message explaining why. The set covers everything from the one-line arenaBaseOffset fix in patch 3 (which I wrote about three weeks ago) up through patches in the high 30s and low 40s that deal with everything from PEM block rewriting to XCOFF build-info sections to go version -m metadata layout. As one specific example: one of the patches rewrites the string "TRUSTED CERTIFICATE" to "CERTIFICATE" in PEM blobs on the fly, because that's how IBM ships the CA bundle on PASE and crypto/x509.AppendCertsFromPEM is very particular about what it considers a certificate.

I'll spare you the other 40. The shape is always the same: write a probe in C or Go, confirm what PASE actually does, write the smallest possible patch, document, move on.

A few highlights, because some of them are funny:

• Patch 18: -p 1 for go test. PASE's XCOFF loader is not thread-safe across fork+exec. Run two parallel compile invocations and roughly half the time, one of them returns a loader error that looks like nothing else on Earth. Workaround: tell go test to be single-threaded. Slow, but the tests pass.

• Patch 22: DWARF subtype sections disabled by default. When go build emits DWARF type info for IBM i, the PASE XCOFF loader takes one look at the result and refuses to load it with the helpful error code 0x213c, which is the ASCII for !<, which is the ar archive magic, which means the loader has wandered off into the middle of an archive and lost its place. Disabled until I figure out which DWARF subtype it's choking on.

• Patch 27/28: cgo resolver forced on. PASE doesn't have /etc/resolv.conf in any place Go's pure-Go resolver knows to look. The cgo resolver, which goes through libc and asks PASE nicely, works fine. So we force the cgo resolver on IBM i. Net result: http.Get works.

• Patch 30: auto-detect gcc-10 or gcc-12. There is no unversioned gcc on PASE. There is a gcc symlink, but it points to gcc-6, whose include-fixed headers are from 2017 and redefine sigset_t incompatibly with everything else on the system. You do not want gcc-6. The patch asks the system "do you have gcc-10? gcc-12?" and picks the newest one that exists.

• Patch 32: cmd/go needs cgo on ibmi. Because of the resolver patch. Because cmd/go does DNS. Because everyone does DNS. This took an embarrassing amount of time to figure out.

Some Free Stuff: db2isql

This is the part that surprised me.

On IBM i, when you want to run SQL ad-hoc, you sign on, you type STRSQL, and you're in a green-screen interactive SQL session. It works. It's been working since 1988. Generations of IBM i administrators have muscle-memory for it.

But if you live in PASE — in ssh, in vim, in shell pipelines — STRSQL is a context switch every time. You leave your terminal, you sign on to a 5250 session, you run the query, you copy the result out by hand. There's no |. There's no >. There's no scripting it from a shell for loop.

The Go port supports cgo. The IBM i ships with libdb400.a, the Db2 SQL CLI library. Putting two and two together: I wrote a database/db2i package — in the Go standard library, alongside database/sql itself — that talks to Db2 for i over the CLI. It's not a database/sql driver, strictly speaking. PASE's threading and connection-lifetime constraints don't fit the driver.Driver interface cleanly, so database/db2i is a partial reimplementation of the same shape of API: Open, Query, Exec, Scan, Close. Familiar enough that anyone who has used database/sql will be at home in five minutes. Different enough that it can do what PASE needs without lying to the runtime.

That was supposed to be a private convenience for the node_exporter collectors. Then I wrapped a 200-line CLI around it called db2isql, and now I reach for it before I reach for STRSQL.

It pipes. It redirects. It returns proper exit codes. You can put it in a shell for loop. And anyone who wants to embed Db2 access into their own Go program just imports database/db2i and gets a working API straight from the standard library — no third-party package, no go get, no module bookkeeping.

STRSQL is still there when you want the interactive experience and the F4 prompts. db2isql is for when you want SQL to behave like every other Unix command.

It cost me about a week to write, of which six full days were spent fighting Db2 CLI quirks on PASE that nobody outside IBM has ever documented in one place. Things like:

• Thread affinity is mandatory. Db2 CLI on PASE refuses to share connections across OS threads. Go schedules goroutines onto threads however it likes. The driver has to runtime.LockOSThread() in Open and runtime.UnlockOSThread() in Close, or the second query after a goroutine migration returns rc=-1 from SQLAllocConnect and you spend a day debugging it.

• SQLGetData is a trap. On PASE PPC64, calling SQLGetData more than ~6 times sequentially against the same row returns 07006. Calling it against a VARGRAPHIC column returns 07006 immediately. The only safe pattern is SQLBindCol once and SQLFetch in a loop. Which is the documented best practice anyway, but it's nice when "best practice" and "the only thing that works" coincide.

• SQLSetConnectOption(AUTOCOMMIT) segfaults. Pass an int 1 as a SQLPOINTER and PASE PPC64 dereferences it like a pointer. Don't call it. The default is autocommit-on. Move on.

All of these are now written down in my notes, so that the next time I don't have to rediscover them sequentially over six days.

node_exporter, At Last

The whole reason for this project was node_exporter. So let's close the loop.

With native Go installed, building node_exporter for IBM i is a 30-second exercise:

Out of the box, most of the standard collectors don't work — they read /proc, which PASE doesn't have. So I wrote twelve IBM i-specific collectors that go through QSYS2 system services instead:

The database/db2i package is what makes these collectors possible. Each collector is a few dozen lines of Go that opens a Db2 connection, runs a SELECT, and writes Prometheus metrics. The Db2 part is invisible to anyone looking at the resulting /metrics endpoint.

The output looks like every other node_exporter on Earth:

…but it also exposes things node_exporter on a Linux box has never heard of. The LPAR collector emits a single info gauge with everything you'd want to alert on baked in as labels:

node_lpar_info{
    machine_type="9009",
    machine_model="22A",
    machine_serial_number="78D7930",
    partition_id="8",
    partition_name="vm-99024459-138560990",
    ipl_type="B",
    ipl_mode="NORMAL",
    cpu_sharing_attribute="CAPPED",
    dedicated_processors="NO",
    hardware_multithreading="YES",
    bound_hardware_threads="YES",
    attention_light="OFF",
    restricted_state="NO",
    shared_processor_pool_id="0",
    partition_group_id="32776"
} 1

Wrap changes(node_lpar_info[5m]) around that in PromQL and you get an alert the moment the attention light comes on, or the partition gets moved by LPM. Things you'd otherwise notice by walking past the HMC.

The sysval collector exposes every system value the OS will tell you about. ~130 numeric and character system values, all carried as Prometheus metrics:

node_system_value{name="QMAXJOB"}      163520
node_system_value{name="QACTJOB"}      200
node_system_value{name="QPWDMINLEN"}   6
node_system_value{name="QPWDMAXLEN"}   8

node_system_value_info{name="QSECURITY",value="50"}        1
node_system_value_info{name="QAUDLVL",value="*SECCFG *SECRUN"} 1
node_system_value_info{name="QCRTAUT",value="*CHANGE"}     1
node_system_value_info{name="QPWDRULES",value="*PWDSYSVAL"} 1

If you've ever wanted to alert when somebody quietly drops QSECURITY from 50 to 40, this is how. changes(node_system_value_info{name="QSECURITY"}[1h]) > 0 and you get a Slack ping within the scrape interval. Same trick works for any system value you care about.

Which means: same Prometheus, same Grafana, same dashboards, same alerts. Drop the binary on every IBM i partition you own, point your existing Prometheus at port 9100, and the IBM i finally joins its AIX and Linux siblings on the same dashboard — except now the IBM i is the one with the most interesting labels.

What You Came Here For

Three downloads. Direct links, no landing page, no clickthrough:

Go 1.25.9 for IBM i — go1.25.9-ibmi-port-45-ibmi-ppc64.tbz (checksum: .sha256).

# On the IBM i target, as any PASE user:
cd $HOME
/QOpenSys/pkgs/bin/tar xjf go1.25.9-ibmi-port-45-ibmi-ppc64.tbz
export PATH=$HOME/go-ibmi-1.25.9/bin:$PATH
export GOTMPDIR=$HOME/tmp     # /tmp can be cleaned without your consent
mkdir -p $HOME/tmp
go version

You should see go version go1.25.9 ibmi-port-45 ibmi/ppc64. Prerequisites you'll want from yum: gcc-10, db2-server-utils, ca-certificates-mozilla. The first go build after install takes tens of seconds while it warms its cache from the standard library; subsequent builds are sub-second.

A self-contained README-IBM-i.md ships inside the tarball with full prerequisites, env vars, and known limitations.

Cross-compilation from macOS or Linux x86_64 works (GOOS=ibmi GOARCH=ppc64), but I'm not shipping bootstrap binaries for those hosts in this release. If you need a cross-compiler, email me or write down the comment.

node_exporter for IBM i — node_exporter. Single binary. Drop it in /opt/node_exporter/, run it from a job description, scrape it on :9100.

db2isql — db2isql. Single binary. db2isql "your SQL here". Pipes work. -f json for when you want to feed it into something else.

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!

What's Next

The XCOFF build-info section isn't right yet, so go version -m <binary> reports "not a Go executable" against IBM i binaries. The binaries are fine — they just don't carry the build metadata in a section the upstream cmd/go knows how to find. That's the next patch.

After that: the loader race is currently worked around with -p 1. I'd like to actually fix it, by pre-warming the loader before cmd/go forks parallel children. That's a multi-week project, but it'll bring parallel builds back and make make.bash 8× faster on a real machine.

But most importantly, before any of that: the Common Europe Congress 2026 in Lyon, France. This is the first and biggest thing on my calendar. I need to be prepared, which means the next chunk of my time goes there. If you want to talk about the port, the collectors, what's missing, what should come next, or just to see the live demo running on a real LPAR — find me at the Congress. Grab me between sessions, corner me at coffee, wave at me across the room. Whatever works. I'd rather have those conversations face-to-face than over email.

If you build something on top of this, tell me. If something breaks, tell me. That's how you help everyone in the community!

Share

Have fun with Go on IBM i!

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.

Look at that list. We have Linux on Power. We have AIX. What's missing?

IBM i.

There's no official node_exporter for IBM i. There are some community projects out there in various languages — Python, Node, the usual suspects — but no proper Prometheus-team node_exporter. That's not a coincidence. It's because there is no Google Go for IBM i. And node_exporter is written in Go.

I asked IBM about a Go port roughly two years ago. The answer was the one you've heard before if you've asked IBM for anything: "if you find a paying customer for it, we'll do it." No customers were forthcoming. The matter rested.

Until two weeks ago, when I thought: Andrey, if you want even an empty-shell node_exporter for IBM i, you need a Go compiler first. Maybe just try it.

So I tried it.

Step 0: Don't Fork. Patch.

The first decision was the most important one. There is already a thing on GitHub called ibmigo, written by Sumit Goyal, who kindly sent me the link when I started poking at this. It works by lying to the Go toolchain — it tells the compiler "I am AIX" and then patches over the places where AIX-the-real and AIX-the-PASE diverge. It's clever and it works, but it's a fork, and forks rot. Every time upstream Go ships a new release, you're rebasing a wall of changes against a moving target.

I wanted a re-baseable patch series against upstream Go, with GOOS=ibmi as a first-class build target. That means: when a new Go version comes out, I run git rebase against the new tag, fix whatever broke, ship it. No fork. No drift. Each patch a small, reviewable, single-purpose change.

This is more work upfront and a lot less work forever. So far I'm at 36 patches and counting.

Step 1: The Heap (Or, A Surprisingly Elegant Fix)

The first real problem was memory.

Go's runtime has a fast path for converting any heap pointer into a metadata-table index. It assumes heap addresses fit in 48 bits, with one fixed offset baked in per platform to handle whatever weird high-bit prefix that OS happens to use.

On Linux: zero offset.

On AIX: addresses live in the range 0x0a00000000000000 and up. So Go's runtime has a constant arenaBaseOffset = 0x0a00... for AIX, hardcoded.

I cross-compiled my first hello-world for IBM i, scp'd it to pub400, ran it, and got:

runtime: memory allocated by OS [0x0700000028000000, ...]
   not in usable address space
fatal error: memory reservation exceeds address space limit

So PASE doesn't put memory at 0x0a000... like AIX does. PASE puts it at 0x07000.... Different upper prefix, same shape of problem. The whole runtime threw up its hands on the very first allocation.

I wrote a small C probe program — mmap a few hundred pages, print the addresses — and confirmed: every PASE allocation has the prefix 0x07000000. Always. The whole 1 TiB Teraspace region lives under that prefix. PASE also ignores mmap hints, by the way, which I confirmed by hinting it five different addresses and watching it return 0x07000000... every single time, smiling pleasantly.

The fix was a one-line addition:

arenaBaseOffset = 0xffff800000000000*goarch.IsAmd64
               + 0x0a00000000000000*goos.IsAix
               + 0x0700000000000000*goos.IsIbmi   // <-- added

That's it. The blocker that has kept Go off PASE since at least 2021 — issue #45017 if you want to look it up — was a single constant. After that, hello-world ran. I almost felt cheated by how easy that was.

The universe, sensing my hubris, then arranged for everything else.

Step 2: PASE Is Mostly AIX, Until It Isn't

Phase 1 was the cross-compiler — build on my Mac, run the binary on pub400. That worked end to end with twelve patches. 8/8 of my test battery green. I felt good. I decided to do Phase 2: a native self-hosted Go toolchain, running on IBM i itself, capable of compiling itself.

That's when PASE got interesting.

A native toolchain means Go's make.bash runs on the target system. Which means every weird thing PASE does that's slightly different from AIX gets exercised, in production, all at once.

A small selection of what fell out:

uname -m returns the system serial number. Not ppc64. Not powerpc. The literal serial number of the machine — 007800001B91 on pub400. Go's build system uses uname -m to figure out what architecture it's running on. It does not know what to do with 007800001B91. Patch: hardcode gohostarch=ppc64 for ibmi, mirroring the existing AIX special case.

fstatat is a stub. Go's os package uses fstatat(dirfd, ...) to do stat-relative-to-a-directory operations. PASE's libc fstatat accepts exactly one value for dirfd: AT_FDCWD. Pass it any real directory file descriptor and it returns EINVAL. I found this out by writing — surprise — another C probe program, watching tests T1, T2, T8 pass and T3 through T7, T9, T10 fail with the same error code. The fix was to route ibmi onto Go's existing statat_other.go fallback path, the same code path used by plan9 and js/wasm — platforms that also don't have a real fstatat. The IBM i is in good company.

Errno isn't cleared on success. This one nearly cost me a full day of debugging the wrong thing. On every Unix you've ever used, a successful syscall doesn't touch errno. On PASE, a successful syscall also doesn't touch errno — but if a previous failed call left a stale value in there, that stale value is still there, and your test program will happily read it and conclude that the current call failed too. I had to add errno = 0 before every probe call. Lesson learned, applied to every probe written since.

The XCOFF loader races itself. This is the one I'm currently sitting on. PASE's dynamic loader is not thread-safe when multiple processes simultaneously resolve imports from the same shared library. Go's build system likes to do exactly that — it spawns parallel compile jobs, each of which forks and execs a fresh compile binary, all of which need libpthreads.a resolved at the same moment. About 50% of the time, two of them step on each other and the build dies with a loader error code. Workaround: pin cmd/go to single-threaded build (-p 1) on ibmi. It's slow but it's deterministic. A real fix is going to need either retry logic in the runtime's exec path or a pre-warm of the loader's cache.

There are more patches like this. I'll spare you them. The shape is always the same: write a probe, confirm what PASE actually does, write the smallest possible patch, document, move on.

Step 3: The Reference Port That Already Did Half The Work

About halfway through Phase 2 I went back to look at ibmigo's git history more carefully — Sumit’s port, the existing fork I'd decided not to use as my base — and found that he had independently discovered most of the same PASE quirks I was hitting. Same -p=1 workaround for the loader race. Same maxbg=1 for the GC. Even the same trick of retrying mkdir in a loop because PASE's syscalls are sometimes spuriously racy.

I'd been worried I was the only one seeing some of this. Turns out: no, this is just what PASE is. Sumit and I have shared confused experiences across years of disconnected effort, and we both ended up at almost identical workarounds. There is some comfort in that.

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!

Where We Are, And Where We're Going

The current state: cross-compile from my Mac to IBM i works cleanly. A native Go toolchain on IBM i builds, but only with GOMAXPROCS=1 and -p=1, and make.bash succeeds maybe half the time because of the loader race. I don't yet trust it enough to publish it. Alpha would be a generous label.

But it compiles things. It runs things. It is real Go, talking to real IBM i.

Once I'm confident the loader race is properly worked around — not just papered over — I'll publish the port. Anyone who wants to download the port and see what happens will be able to do so. After that comes node_exporter. And after that, the IBM i finally gets to join its AIX and Linux siblings in the same Prometheus dashboard, scraped on the same port 9100, looking like every other host on the network.

Wait a bit. You'll most probably get it.

Thanks

This work would have been considerably harder, and possibly impossible at this speed, without pub400.com — the free public IBM i system run by Holger Scherer. Every probe program in this article ran on pub400. Every "okay but does PASE actually do this?" question got answered there. Holger has been running this service for years, free of charge, for the IBM i community. If you're doing anything with IBM i and you don't have your own LPAR handy, pub400 is where you go. Holger, thank you.

Thanks also to Sumit Goyal, who built the ibmigo port and sent me the link when I started this. Several of the trickier PASE workarounds in my patch series — the loader-race mitigations especially — exist in something like their current form because Sumit got there first and his repo is public. Independent confirmation that you're not hallucinating a problem is worth a lot when you're three days into debugging a 50%-flaky build.

Share

Have fun porting software to your favorite platform!

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.

This week, let's assemble it all. Like an IKEA wardrobe, except the instructions are in English, the screws are all accounted for, and nobody ends up sleeping on the floor.

If you already have nmon/njmon running on your AIX boxes — and you probably do — that's a perfectly good wardrobe you don't have to throw out. There's a way to bolt it onto the new one. That's at the end. Stick around.

Step 1: Decide Where The Wardrobe Goes

Prometheus needs to live somewhere. Pick the wall before you start drilling, because moving it later is annoying. The somewhere has three constraints, in order of how much they actually matter:

Network reach. Whatever host runs Prometheus has to be able to open TCP connections to every server you want to scrape. If your AIX LPARs are on one VLAN and your x86 monitoring infrastructure is on another with a firewall between them, you'll be filing tickets. Putting Prometheus inside the Power environment — on a Linux on Power LPAR or on AIX itself — usually saves you that fight.

Disk. Prometheus writes a lot. Plan for ~1-2 bytes per sample, ~15s scrape interval, ~500 samples per scrape per node_exporter target. That’s roughly 3-6 GB per host per year at default retention (15 days), but you’ll want longer retention than that, and you’ll want headroom. SSD or fast SAN. Don’t put the TSDB on NFS. It will hurt you.

CPU and RAM. Modest. A single Prometheus instance scraping a hundred hosts every 15 seconds will run happily in 2 VPs and 4 GB. Scale up from there only when you have evidence you need to.

What does that mean concretely?

• Linux on Power LPAR — my default recommendation. Same architecture as your AIX boxes, so it sits right next to them on the network. Standard prometheus package from your distro or from the Prometheus site. Boring. Works.

• AIX LPAR — use the port from last week's newsletter. Useful when you want everything inside AIX and not depending on a Linux jump box. Less boring. Beta quality warning.

• x86 Linux VM — fine if it has clean network reach into your Power environment. Most shops already have one running for the rest of their fleet, and adding Power targets to an existing Prometheus is the path of least resistance.

Pick one. Don't overthink it. You can move the wardrobe later — the config is a YAML file and the data is a directory.

Step 2: Attach A node_exporter To Every Panel

For each AIX and Linux on Power host you want to monitor, drop node_exporter in, run it, point Prometheus at port 9100. That's the whole shape. These are the dowels — small, identical, and you need one in every hole.

On a single host, by hand, it looks like this on AIX:

mkdir -p /opt/node_exporter
cd /opt/node_exporter
gzip -dc /tmp/node_exporter-aix-ppc64.tar.gz | tar xf -
./node_exporter &

And then in /etc/inittab:

nodeexp:2:respawn:/opt/node_exporter/node_exporter >/dev/console 2>&1

On Linux on Power, it's the same idea with systemd instead of inittab. Doing this fifty times by hand is the part where you give up and call your spouse for help. So:

Step 3: Ansible, The Cordless Drill

Here's a minimal playbook that handles both AIX and Linux on Power. The conditional logic is unavoidable — the platforms genuinely differ in how services start — but it's all in one place.

---
- name: Deploy node_exporter on IBM Power
  hosts: all
  gather_facts: true
  become: true

  vars:
    node_exporter_version: "1.11.1"
    node_exporter_user: "nodeexp"
    node_exporter_dir: "/opt/node_exporter"

  tasks:
    - name: Create node_exporter user (AIX)
      ibm.power_aix.user:
        state: present
        name: "{{ node_exporter_user }}"
        change_passwd_on_login: false
        attributes:
          home: "{{ node_exporter_dir }}"
          shell: /bin/false
      when: ansible_system == "AIX"

    - name: Create node_exporter user (Linux on Power)
      ansible.builtin.user:
        name: "{{ node_exporter_user }}"
        system: true
        shell: /bin/false
        home: "{{ node_exporter_dir }}"
        create_home: false
      when: ansible_system == "Linux"

    - name: Create install directory
      ansible.builtin.file:
        path: "{{ node_exporter_dir }}"
        state: directory
        owner: "{{ node_exporter_user }}"
        mode: "0755"

    - name: Copy node_exporter binary (AIX)
      ansible.builtin.copy:
        src: "files/node_exporter-aix-ppc64"
        dest: "{{ node_exporter_dir }}/node_exporter"
        owner: "{{ node_exporter_user }}"
        mode: "0755"
      when: ansible_system == "AIX"

    - name: Copy node_exporter binary (Linux on Power)
      ansible.builtin.copy:
        src: "files/node_exporter-linux-ppc64le"
        dest: "{{ node_exporter_dir }}/node_exporter"
        owner: "{{ node_exporter_user }}"
        mode: "0755"
      when: ansible_system == "Linux"

    - name: Install systemd unit (Linux)
      ansible.builtin.copy:
        dest: /etc/systemd/system/node_exporter.service
        content: |
          [Unit]
          Description=Prometheus node_exporter
          After=network.target

          [Service]
          User={{ node_exporter_user }}
          ExecStart={{ node_exporter_dir }}/node_exporter
          Restart=on-failure

          [Install]
          WantedBy=multi-user.target
      when: ansible_system == "Linux"
      notify: restart node_exporter linux

    - name: Add node_exporter to inittab (AIX)
      ibm.power_aix.inittab:
        state: present
        name: nodeexp
        runlevel: "2"
        action: respawn
        command: "{{ node_exporter_dir }}/node_exporter >/dev/null 2>&1"
      when: ansible_system == "AIX"
      notify: reload inittab

  handlers:
    - name: restart node_exporter linux
      ansible.builtin.systemd:
        name: node_exporter
        state: restarted
        enabled: true
        daemon_reload: true

    - name: reload inittab
      ansible.builtin.command: init q

That's the whole deployment story for ten or ten thousand hosts.

Then point Prometheus at them:

scrape_configs:
  - job_name: 'power-aix'
    static_configs:
      - targets:
          - aix01.example.com:9100
          - aix02.example.com:9100

  - job_name: 'power-linux'
    static_configs:
      - targets:
          - lop01.example.com:9100
          - lop02.example.com:9100

Should I write a playbook for you to add all your AIX and Linux on Power servers to the config?

Reload Prometheus, query up, see ones, profit.

Step 4: The Wardrobe You Already Own

Here's the thing. If you've been running AIX for any length of time, you probably already have njmon. Probably with crontabs and dashboards and people who have opinions about it. That's the perfectly good wardrobe from the intro. Don't throw it out — bolt it on.

node_exporter gives you the standard ~150 metrics that Prometheus people expect. njmon gives you on the order of 1500 — every disk, every adapter, every CPU, every workload class. It's much more detailed than node_exporter, especially for the Power-specific stuff that the Linux-world node_exporter doesn't know exists.

You don't have to choose. You can run both, and you can feed njmon data into the same Prometheus.

There are two routes. Pick one.

Route A: Telegraf as a translator (the well-trodden path)

This is the route Nigel Griffiths himself documents on the IBM site, and it's the one most shops end up on. The shape:

• njmon (or better, nimon — same tool, InfluxDB Line Protocol output) runs on each AIX host and pushes its metrics out over the network.

• One telegraf instance — could be the same Linux-on-Power or AIX box hosting Prometheus — receives those pushes from all your AIX hosts on a single port via the inputs.influxdb_listener plugin. You don't need a Telegraf per AIX node; one funnel handles the whole fleet.

• Telegraf re-exposes the metrics as a Prometheus-format /metrics endpoint via the outputs.prometheus_client plugin.

• Prometheus scrapes Telegraf like any other target.

The funnel: AIX → push → Telegraf → pull ← Prometheus.

On the AIX side:

nimon -s 30 -c 2880 -i telegraf-host.example.com -p 8080

That tells nimon to send a sample every 30 seconds, for 2880 iterations (24 hours), to your Telegraf host on port 8080. Run it from /etc/inittab for production.

On the Telegraf side, a minimal telegraf.conf:

[[inputs.influxdb_listener]]
  service_address = ":8080"

[[outputs.prometheus_client]]
  listen = ":9273"

And in Prometheus:

- job_name: 'aix-njmon'
    scrape_interval: 60s
    static_configs:
      - targets: ['telegraf-host.example.com:9273']

A note on topology: you only need one Telegraf instance, not one per AIX host. All your nimon clients push to the same telegraf listener, and Prometheus scrapes that one endpoint. Put it on the same Linux on Power LPAR as Prometheus and you're done. If you'd rather run it on AIX itself — say, to keep the whole stack inside AIX — the AIX BFF is here: https://dl.power-devops.com/powerdevops.telegraf.1.29.4.1.bff.gz.

A note on scrape timing: njmon is pushing every 30 seconds; Prometheus should scrape Telegraf at 1.5–2× that interval (so 60s is fine) to avoid catching half-written batches.

Route B: njmon_exporter (the direct path)

There's also njmon_exporter — a Go exporter purpose-built for this. It listens on port 8086 for njmon JSON pushes and re-exposes them on 9772 for Prometheus. No Telegraf in the middle.

Worth knowing before you reach for it: the README still says WIP — currently in development, and the repo has 5 stars. It works, and it's a smaller moving-parts count than the Telegraf approach, but it has fewer eyes on it. If your shop already runs Telegraf for other reasons, Route A is the boring choice. If you want one less daemon and you don't mind reading Go when something breaks, Route B is right there.

Either way, the AIX side stays the same — njmon -k -s 60 -i <collector> -p <port> from inittab or cron — and you end up with the full ~1500-metric firehose available in the same Prometheus, queryable next to your node_exporter data.

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!

Step Back And Look At It

If you've followed along over the last few weeks:

• A Prometheus server, somewhere it can reach your Power LPARs.

• node_exporter on every AIX and Linux on Power host, scraped on :9100.

• (Optional but recommended) njmon data flowing into the same Prometheus via Telegraf or njmon_exporter, giving you the deep AIX-internal metrics that node_exporter doesn't expose.

• One Grafana, one PromQL, one alerting setup, one place to look.

Point a Grafana at this Prometheus and pick from the existing node_exporter dashboards. They mostly work as-is — the metric names are the same on AIX as everywhere else, which was the entire point of using node_exporter in the first place. The njmon metrics will be named differently (whatever njmon/Telegraf chose for them), so you'll either build dashboards for those or import community ones.

That's the stack. It's the same Prometheus everyone else runs. It just happens to be looking at IBM Power. No leftover screws.

If you build this and it works, tell me. If you build this and something breaks in a way I didn't warn you about, tell me — that's how the next newsletter writes itself.

Share

Have fun monitoring IBM Power with Prometheus!

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.

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