20 years ago we didn't have REST APIs

But sometimes we still manage old devices

How would life be better if we could use only the newest hardware and software? Just imagine it! You start Ansible and everything works from scratch. Your HMC automatically opens PMRs and sends all related information to IBM without you. Of course, you have only the brand new Power11 servers in the datacenter. So nice life! Unfortunately, many of us still have old hardware and old software. We must manage it with newer tools, but how?

I wanted to automate AIX deployments. It is easy! I promise, I will write about it. Meanwhile, if you are in Switzerland, Austria, or Germany, you can register for the free IBM workshop in Zurich, where you will do it together with me and my friends Alexander Paul and Stefan Gocke. The link is below.

To automate a deployment, and it doesn’t matter whether we talk about AIX, Linux, or Windows, you must not only create a virtual machine and install an operating system. You must also prepare the underlying infrastructure and make some initial configuration of the system. Like configuring network and SAN switches, or DNS entries.

Ansible can help everywhere!

My old Brocade switches

So what's the problem? I have Brocade switches. They have Fabric OS. Brocade has an Ansible collection to manage them.

Download the collection and start using it!

Nope, it doesn’t work in my case.

The collection requires Fabric OS 8.2.1c or newer. What do you think, which version is installed on my IBM-branded Brocade switches? 8.2.0a.

They have a REST API already, but this REST API is a different type of REST API, and the Ansible collection doesn’t work with it.

You may propose to upgrade the switches, and I agree entirely with you.

The only problem is that even if I wrote “my Brocade switches,” they are not mine, indeed. Another guy is responsible for their upgrade, and for some reason, he can’t upgrade them right now.

What can I do? Search for a solution!

FabricOS SSH interface

REST API is not the only interface used by Fabric OS. A much older interface is SSH. You can connect to the switches using SSH and issue commands.

If we can use SSH, we can use Ansible! Even if there is no Python on Brocade switches, we can use the ansible.builtin.raw module to issue “raw” commands. Like:

---
- name: Get Fabric OS version
  hosts: localhost
  connection: local
  gather_facts: false

  tasks:
    - name: Get Fabric OS version
      ansible.builtin.raw: ssh switch version
      changed_when: false
      register: fos_ver

    - name: Show Fabric OS version
      ansible.builtin.debug:
        var: fos_ver.stdout_lines

It works:

But what happens if you want to create a new zone? Remember, I talked about deployments. After we create an LPAR with NPIV, we must zone it in the SAN.

In this case, we usually create aliases, then zones, add the zones to the SAN configuration, and activate the configuration. These are multiple commands that must be executed in one session. If we simply create an alias and then our SSH session is dropped, the alias is not saved and dropped together with our SSH session.

You can specify multiple commands in one task with the raw module:

- name: Multiple commands
  ansible.builtin.raw: |
    hostname
    date

But these commands are executed locally on your Ansible control node. You can prepend each command with ssh, but this will start two different SSH sessions. They will not interact with each other.

You can try to write multiple Fabric OS commands, separating them by semicolon:

---
- name: Get Fabric information
  hosts: localhost
  connection: local
  gather_facts: false

  tasks:
    - name: Get Fabric information
      ansible.builtin.raw: ssh sanswitch "version ; fabricshow"
      changed_when: false
      register: fos_info

    - name: Show Fabric information
      ansible.builtin.debug:
        var: fos_info.stdout_lines

It works. You must only add “cfgsave -f” after each Fabric OS command to save the new configuration, like:

---
- name: Create new zone
  hosts: localhost
  connection: local
  gather_facts: false

  tasks:
    - name: Create alias for LPAR fcs0
      ansible.builtin.raw: ssh sanswitch 'alicreate lpar_fcs0, "01:02:03:04:05:06:07:08"; cfgsave -f'

    - name: Create alias for LPAR fcs1
      ansible.builtin.raw: ssh sanswitch 'alicreate lpar_fcs1, "08:07:06:05:04:03:02:01"; cfgsave -f'

    - name: Create zone for LPAR fcs0
      ansible.builtin.raw: ssh sanswitch 'zonecreate zone_lpar_fcs0, "lpar_fcs0; flash_system_1"; cfgsave -f'

    - name: Create zone for LPAR fcs1
      ansible.builtin.raw: ssh sanswitch 'zonecreate zone_lpar_fcs1, "lpar_fcs1; flash_system_2"; cfgsave -f'

    - name: Add zones to the SAN config
      ansible.builtin.raw: ssh sanswitch 'cfgadd MYCFG, "zone_lpar_fcs0;zone_lpar_fcs1"; cfgsave -f'

    - name: Activate new SAN config
      ansible.builtin.raw: ssh sanswitch 'cfgenable MYCFG -f' 

Don’t forget to repeat it for the second fabric, and have a lot of fun searching for errors.

Would it work? Maybe I really didn’t want to try. I continue searching for a better solution.

Did I find a better solution?

Not really. What I found was an old Brocade Python library to execute simple commands on Fabric OS using the SSH interface.

I could use it as it is, but I prefer the new way of using Ansible collections. I had experience creating Ansible collections. I hope you use my PowerHA collection, which is certified by Red Hat.

So I created a new collection - enfence.fos. No, I don’t have plans to certify it, and yes, it is more like a beta version right now.

The collection has only one module - command. The module does what it says - it executes commands on FabricOS using the SSH interface.

Like the Ansible command module, it doesn’t control which commands you write, and it is NOT idempotent.

The most significant advantage of the module is that you can specify multiple commands and they will all be executed in one session. You can also specify prompts that you want to automatically answer. My huge thanks to the original developer of the Python library - Chip Copper.

For the use case above, the code looks like:

- name: Create SAN configuration for the LPAR
  enfence.fos.command:
    credential:
      fos_ip_addr: sanswitch
      fos_username: admin
    commands:
      - cmd: alicreate lpar_fcs0, "01:02:03:04:05:06:07:08"
      - cmd: alicreate lpar_fcs1, "08:07:06:05:04:03:02:01"
      - cmd: zonecreate zone_lpar_fcs0, "lpar_fcs0; flash_system_1"
      - cmd: zonecreate zone_lpar_fcs1, "lpar_fcs1; flash_system_2"
      - cmd: cfgadd MYCFG, "zone_lpar_fcs0;zone_lpar_fcs1"
      - cmd: cfgenable MYCFG -f
  changed_when: true

If you are an experienced SAN administrator, I hope you find it much cleaner than to use the ansible.builtin.raw module. And more familiar.

Are you in Switzerland, Austria, or Germany? Then this information is for you.

The following information is in German. If you are from the non-German-speaking part of Switzerland, please contact Hermann (see below, Anmeldung). If we have enough non-German-speaking participants, we will make the workshop in English. Or, we will think about making it one more time for English speakers.

Einladung zum ETS-Ansible Automation Workshop 2.0 für IBM Power Systems

Wann: 18.–19. September 2025
Wo: IBM Auditorium, IBM Schweiz AG, Vulkanstrasse 106, Postfach, 8010 Zürich
Beginn: 09:30 Uhr
Anmeldung: hermann.huber@ch.ibm.com
Kosten: Keine

🧑‍🏫 Trainer & Experten

• Alexander Paul – IBM, Senior Technical Consultant

• Andrey Klyachkin – IBM, Senior Technical Consultant

• Michael Fiebig – IBM, Systems Engineer (Server Setup Lab Umgebung)

• Stefan Gocke – IBM Business Partner

📋 Agenda

Tag 1 – Deployment & Automatisierung

Vormittag: Einführung und Grundlagen

• Einführung in Ansible: Funktionsweise und Architektur

• Installation von Ansible auf Linux & AIX

• Vorbereitung der Ansible-Umgebung

• Ansible Workspace einrichten

• Notwendige Collections herunterladen

• Zugriff auf Systeme prüfen (HMC, PowerVC, Storage, …)

• Erstes Playbook: System-Ping

• Unterschiede HMC vs. PowerVC für LPAR-Deployment

Nachmittag: LPAR Deployment & Automatisierung

• LPAR Deployment: HMC oder PowerVC als Basis

• OS-Installation (AIX, RHEL, SLES) und erste Konfiguration

• LVM-Konfiguration: Volume-Gruppen, LVs, Filesysteme

• Application Deployment: Oracle auf AIX oder Apache auf RHEL

• OS-Tuning für spezifische Workloads

• Ansible Automation Platform (AAP): Deployment über AAP

• Herausforderungen und Unterschiede zur manuellen Ansible-Nutzung

---

Tag 2 – Betrieb & Performance-Tuning

Vormittag: Ansible im Betrieb

• Warum Ansible für den Betrieb von Power-Systemen?

• Netzwerk-Konfiguration & Performance-Tuning

  • Virtual Ethernet auf VIO/AIX/RHEL

  • Shared Ethernet Adapter (SEA)

  • SR-IOV für VIO/AIX/RHEL

• Storage & LVM Performance

  • VSCSI-Setup und Optimierung

  • FC-HBA-Tuning für NPIV & Storage-Anbindung

  • Monitoring von pbuf, fsbuf & LVM-Konstrukten

Nachmittag: Updates & Security Management

• Updates & Security Patching mit Ansible

  • VIO/AIX/RHEL Update-Prozesse

  • Security-Patching für VIO/AIX

  • Automatisierte Softwareverwaltung mit NIM

• Best Practices & Troubleshooting

  • Typische Fehler und Lösungsansätze

  • PowerVC-Integration und mögliche Herausforderungen

All problems solved?

No.

I hope you didn’t expect that everything would work fine from the very beginning.

The second biggest problem is determining whether something was changed. Now, the module always delivers that nothing has changed on Fabric OS. You must specify changed_when to distinguish between OK and Changed statuses.

The biggest problem is that FabricOS doesn’t know any error codes. You can call alicreate several times with the same parameters. You will get an error message in stdout, and the return code is always 0.

It means you must save the output in a variable and use failed_when to determine if the commands were executed properly.

But still, I have a tool to play with! You too!

Have fun automating old Brocade switches!

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.