Upgrading to VIOS 4.1 means install the latest service pack on VIOS 3.1 first!

Let's install it using Ansible!

Yes, you can! You can upgrade almost any VIOS version from 3.1 to 4.1, and it will most likely work. BUT! IBM employees are humans, not robots. They can’t test every possible combination of hardware and software in the world to be sure that your upgrade path will work without any problems. That’s why there are “supported” VIOS levels you can upgrade to VIOS 4.1. Let’s install the latest service pack before we upgrade VIOS.

Frankly speaking, this is a generic VIOS update playbook. If you have already upgraded your VIOS to 4.1, you can use the playbook to install a service pack on it.

Define our target configuration

Let’s start defining what we want to achieve. Everything must be parameterized, and we use variables in Ansible for it. We must know where the service pack code is (the variables repo_node - NFS server, and repo_dir - the share on the NFS server), which version it is (the variable target_level), and where we want to mount our NFS share (the variable local_dir).

I don’t know why I still use the last variable. You can always create a new temporary directory, mount the NFS share there, and unmount and delete it after you finish.

Check your current VIOS version

Before installing the service pack, we must check if we occasionally have a newer VIOS version. You don’t want to break your working configuration, do you?

- name: Get current VIOS level
  ansible.builtin.command:
    cmd: /usr/ios/cli/ioscli ioslevel
  register: ioslevel
  changed_when: false

The rest of the playbook goes into a block. The block is only executed if we must update.

- name: Update VIOS
  when: "ioslevel.stdout is version(target_level, '<')"
  block:
    - name: Print current VIOS version
      ansible.builtin.debug:
        msg: "Current VIOS version {{ ioslevel.stdout }} is not the same as required: {{ target_level }}"

Remove interim fixes

I don’t know how you fight with the interim fixes, but I prefer to remove them manually before updating VIOS. OK, “manually” is in quotes because I use Ansible for it.

- name: Get list of installed fixes
  ibm.power_aix.emgr:
    action: list
  register: fixes

- name: Remove fix
  ibm.power_aix.emgr:
    ifix_label: "{{ item.LABEL }}"
    action: remove
  loop: "{{ fixes.ifix_details }}"
  loop_control:
    label: "{{ item.LABEL }}"

Unmount ISO images

I use ISO images on VIOS from time to time. I hope you didn’t expect me to unmount all of them. Like every other human being in the world, I forget it sometimes. But if an ISO image is mounted, you can’t install VIOS fixpak. It will fail. We need to check and unmount all ISO images if we have any.

- name: Get list of mounted ISOs
  ansible.builtin.command:
    cmd: "/usr/ios/cli/ioscli lsrep -field optical -fmt :"
  changed_when: false
  failed_when: false
  register: mounted_iso

- name: Unmount ISO image
  ansible.builtin.command:
    cmd: "/usr/ios/cli/ioscli unloadopt -release -vtd {{ item }}"
  changed_when: true
  when: item != "" and item != "None"
  loop: "{{ mounted_iso.stdout_lines }}"

Commit previous updates

The last step before installing a new update is to commit previous updates. In “normal” life, I would use the Ansible module provided by IBM:

- name: Commit updates
  ibm.power_vios.updateios:
    action: commit

The module works, but only if there is something to commit. If there is nothing to commit, the module fails—or failed when I tested it.

I tried to use the updateios command directly, but it also fails if there is nothing to commit. What was most annoying was that the command brought different return codes if there was nothing to commit on different VIOS versions. So I ended with the following snippet:

- name: Commit all uncommitted updates
  ansible.builtin.command:
    cmd: /usr/ios/cli/ioscli updateios -commit
  register: result
  failed_when: ( result.rc not in [ 0, 19, 20 ] )
  changed_when: result.rc == 0

Return codes 19 or 20 mean that there is nothing to commit. Return code 0 means that the command committed the updates.

Mount NFS share and update VIOS

Now, we are ready to take the most important step: updating our VIOS. Of course, we must first mount the NFS share with the new code.

- name: Mount remote repository with updates
  ibm.power_aix.mount:
    state: mount
    node: "{{ repo_node }}"
    mount_dir: "{{ repo_dir }}"
    mount_over_dir: "{{ local_dir }}"

For several years my last step was to use the updateios module and trust to its result:

- name: Update VIO server
  ibm.power_vios.updateios:
    action: update
    device: "{{ local_dir }}"
    install_new: true
    accept_licenses: true
    force: true

The latest update VIOS 4.1.1 changed my mind. This simple snippet produced an error even if the VIOS was updated. But because the return code was not 0, the module failed. As a result I added the option to ignore failures and check now what is in the output of the module:

- name: Update VIO server
  ibm.power_vios.updateios:
    action: update
    device: "{{ local_dir }}"
    install_new: true
    accept_licenses: true
    force: true
  failed_when: false
  register: updateout

- name: Ensure VIO is updated
  ansible.builtin.assert:
    that:
      - '"to be rebooted" in updateout.stdout'
    fail_msg: "VIOS update failed. {{ updateout.stdout }}"
    success_msg: "VIOS update succeeded. The system will be rebooted."

It is easy to find another system administrator today, but it is difficult to find an engineer who can build robust and scalable automation!

Want to become the most valuable professional in your company? Learn to build robust and scalable automation! Yes, it takes time and money, but be sure—the investment pays off. Read more and sign up for the program!

Reboot VIOS

After the service pack was successfully installed, we must reboot VIOS.

- name: Reboot VIO server
  ibm.power_aix.reboot:
    reboot_timeout: 600
  when: '"to be rebooted" in updateios.stdout' 

After the VIOS comes back, it has the newest code!

As a note, don’t try to run the playbook on all your VIOSes at the same time—it will reboot all of them.

Have fun with VIOS updates!

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.