IBM VIOS 3.1.4.41 to 4.1.2.10 Migration Guide

Introduction

Upgrading a VIOS pair differs from upgrading a normal AIX LPAR: VIOS provides virtual storage, networking, and NPIV connectivity to client partitions, so the upgrade has to be planned around availability, not just installed like a new operating system.

Both VIOS servers in this HA pair started on 3.1.4.x with redundant SEA connectivity and NPIV. The migration ran one VIOS at a time, so the other kept serving I/O throughout. The target release was VIOS 4.1.2.10; the environment was first brought to 3.1.4.41, the required intermediate level for this path.

VIOS 3.1.4.21
   ↓
VIOS 3.1.4.41
   ↓
VIOS 4.1.2.10

Migration Approach

The key principle: never upgrade both VIOS servers at once. Move traffic off the VIOS being upgraded, confirm the partner is carrying it, then migrate. VIOS2 went first here, and its installation image was reused for VIOS1.

VIOS2 went first while VIOS1 carried traffic; VIOS1 followed only after VIOS2 was verified healthy. Both were never upgraded at the same time.

Prerequisites for VIOS 3.1.4.41 → 4.1.2.10 Migration

Work through these checks before starting. Some are general IBM viosupgrade requirements; others are conditional and only apply if your environment uses that feature. Not every item applies to every VIOS.

General Prerequisites

1. Supported Power System — confirm VIOS 4.1 is supported on your Power System/model before migrating.
2. Supported VIOS starting level — must be on a supported 3.1 level; this migration starts from 3.1.4.41. Still on 3.1.4.21? See the upgrade guide referenced in the introduction.
3. VIOS 4.1 installation image — the target image/mksysb must be available. Used here: VIOS_Base_Install_4.1.2.10_Flash.iso.
4. A completely free alternate disk — viosupgrade requires a fully free disk (lspv -free); verify it's genuinely unused before specifying it with -a. See Pre-Migration Checks.
5. VIOS configuration backup — take a viosbr backup and copy it off the VIOS. See Take a VIOS Configuration Backup.
6. Customized files/configuration — viosupgrade is a fresh install; use viosupgrade -g to restore/copy files onto the new rootvg.
7. Additional software — check for VIOS applications, third-party multipath software, or Expansion Pack software; a custom mksysb may be required per IBM's viosupgrade requirements.
8. Rootvg-backed vSCSI LVs — determine whether any rootvg LVs back virtual SCSI disks; IBM identifies this as unsupported for restoration. In this migration's test NIM LPAR, NIM-P10-Disk1 fell into this category — see Pre-Migration Checks.
9. Additional alternate-disk ownership check — if the candidate alternate disk has existing Volume Manager ownership, verify whether the ownership needs to be cleared before using it for the migration. The chpv -C hdiskX command can be used for this purpose when applicable. This command must be run as root and should only be used after confirming that the disk contains no required data and is not part of a required volume group. This check was not required in my migration because the alternate disk was new and unused.

Conditional Checks

These apply only if your environment uses the feature in question, since this environment (per the summary above) was a plain SEA/NPIV pair. Treat them as general guidance, not a description of what ran here.

Shared Storage Pool (SSP): if the VIOS belongs to an SSP cluster, IBM has additional requirements: the cluster must be in a supported state before migration, and the appropriate viosupgrade procedure uses the cluster option when required. Verify cluster status first:

cluster -status -verbose

Active Memory Sharing (AMS): IBM's current VIOS 4.1 upgrade guidance requires AMS to be unconfigured before upgrading when AMS is configured. If AMS is configured in your environment, follow IBM's procedure to unconfigure it before migration.

NVMe over Fabrics / SAN boot: if the VIOS uses NVMe over Fabrics or an NVMe-based SAN boot configuration, review IBM's specific upgrade requirements before proceeding.

Third-party multipath software: verify that any third-party SAN multipath software in use is supported on the target VIOS release before migrating.

Operational Checks for Dual-VIOS Environments

Operational/HA checks for a dual-VIOS setup like this one, separate from IBM viosupgrade software prerequisites. Before migrating one VIOS:

• The partner VIOS should be healthy.
• SEA/HA redundancy should be verified.
• The VIOS being migrated should be placed in the appropriate standby/backup state first.
• Only one VIOS should be migrated at a time.
• The partner VIOS should continue providing the required I/O services throughout.

See Move SEA Activity to the Partner VIOS for how this was done in this migration.

1Pre-Migration Checks

Confirm the current VIOS level and identify the disks. Here, the active rootvg was on one disk and the second was unused, making it a candidate alternate disk.

ioslevel

lspv

lspv -free

Verify the alternate disk is genuinely unused and holds no production data or active volume group before trusting it to viosupgrade. Don't assume it's safe just because it appears free — here, hdisk1 was verified unused and selected.

lsdev -Cc disk | grep hdisk

bootinfo -s hdisk0
bootinfo -s hdisk1

2Take a VIOS Configuration Backup

A configuration backup should be taken before migration. In this migration the backup was first created under /home/padmin:

hostname
viosbr -backup -file /home/padmin/viosbrbkp_pre_3.1.4.41

Verify that the backup file exists:

ls -l /home/padmin/viosbrbkp_pre_3.1.4.41*

/home is part of rootvg, so /home/padmin is only a working location, not external storage. Copy the backup to an approved external/remote location before migration so it survives even if rootvg is lost or overwritten.

Also maintain a system-level recovery backup per your organization's procedure; the alternate-disk migration itself is not a substitute for one.

VIOS2

VIOS1

3Prepare the VIOS 4.1.2.10 Image

The migration used the IBM VIOS Flash ISO VIOS_Base_Install_4.1.2.10_Flash.iso, already present in the current directory.

ls -lh VIOS_Base_Install_4.1.2.10_Flash.iso

viosupgrade builds the installation image needed for a local migration. A dedicated directory on the backup filesystem kept the generated files separate from normal backup data.

mkdir -p /viosbackup/vios41210_migration_iso

viosupgrade -I ./VIOS_Base_Install_4.1.2.10_Flash.iso \
  -w /viosbackup/vios41210_migration_iso

Afterward, verify the generated iosmksysb image exists under that directory. The command output should confirm the mksysb was created successfully.

ls -lh /viosbackup/vios41210_migration_iso/viosupg/

4Move SEA Activity to the Partner VIOS

The VIOS being migrated shouldn't carry active network traffic. First confirm which SEA is primary/backup, and identify the actual Shared Ethernet Adapter, since device names vary between environments:

lsdev -Cc adapter | grep -i "Shared Ethernet Adapter"

Use the reported device in place of <SEA_DEVICE> below. Here it was ent10, but this varies by environment.

entstat -d <SEA_DEVICE> | egrep -i "State|Active|Priority|LAN state"

The VIOS being upgraded was placed into standby so its partner could become the active SEA:

chdev -dev <SEA_DEVICE> -attr ha_mode=standby

Then verify both VIOS servers. The partner should carry the active SEA role while the one under maintenance is in backup/standby:

entstat -d <SEA_DEVICE> | egrep -i "State|Priority|Active|LAN state"

VIOS1

5Start the Alternate-Disk Migration

With traffic moved to the partner and the alternate disk confirmed, use the generated iosmksysb image for the local migration:

viosupgrade -l \
  -i /path/to/iosmksysb \
  -a hdisk1

Replace the image path with the actual iosmksysb from the previous step, and use the intended free disk.

viosupgrade runs several checks (MPIO verification, config backup), then installs the new image onto the alternate disk and prepares the bootlist.

VIOS2

VIOS1

6Reboot into VIOS 4.1.2.10

Once installation completes, viosupgrade reports the bootlist set to the new disk. Reboot to finish.

VIOS2

VIOS1

First confirm the upgrade reports successful completion and the system is ready for the new rootvg to become active:

viosupgrade -l -q

Then reboot during the approved maintenance window:

shutdown -restart

Console behavior and reboot duration vary by Power system. Monitor until it boots from the new rootvg.

VIOS2

VIOS1

7Verify the New VIOS Installation

After reboot, the first check is the VIOS level:

ioslevel

The expected target in this migration is:

4.1.2.10

Then verify the physical volumes and confirm the new rootvg is active. The new rootvg may sit on the previously unused disk while the old one appears as old_rootvg, which is normal for this method, not a failed upgrade.

lspv

bootlist -m normal -o

The bootlist may then show the new rootvg disk as the normal boot disk:

hdisk1 blv=hd5 pathid=0

VIOS2

VIOS1

8Validate SEA and Network Connectivity

Next, check SEA state and confirm the migrated VIOS rejoined the HA pair.

entstat -d <SEA_DEVICE> | egrep -i "State|Priority|Active|LAN state"

Depending on SEA mode, the pair may report PRIMARY/BACKUP or PRIMARY_SH/BACKUP_SH. Here, it settled as PRIMARY_SH/BACKUP_SH with LAN_OPERATIONAL on both interfaces. That's the state for this environment, not a requirement for every SEA setup.

Right after both VIOS were migrated, the pair briefly showed a plain PRIMARY/BACKUP split (VIOS1 backup, VIOS2 primary), a transitional state rather than an error. It resolved once SEA sharing was restored in the next step.

Don't force a particular state just because the text looks different. Validate the configured HA mode and actual traffic behavior before changing SEA settings.

9Validate NPIV

Check NPIV connectivity after reboot, since virtual Fibre Channel adapter relationships are essential to client storage access.

lsmap -all -npiv

A healthy client shows a logged-in state with the expected adapter and ports. This environment showed an NPIV adapter in LOGGED_IN state with multiple ports logged in.

Also validate client-side multipathing and storage access from a representative client LPAR. The VIOS-side check alone doesn't prove every production path is healthy.

10Validate Storage and VIOS Configuration

Review the VIOS mappings and physical Fibre Channel adapters after migration. Useful checks include:

lsmap -all
lsmap -all -npiv
lsdev -Cc adapter | grep -i "Fibre"
lsdev -Cc adapter | grep -i "Shared Ethernet"

Confirm that expected adapters are available and that no unexpected mapping or device state appeared during the migration.

If using SAN multipathing, also validate client LPAR paths, e.g.:

lspath

11Restore Normal SEA Operation

Once fully validated, restore the intended SEA HA configuration. Confirm the pair actually returns to the expected sharing states rather than assuming one attribute change is enough.

The final healthy state observed in this migration:

VIOS1  → PRIMARY_SH
VIOS2  → BACKUP_SH

Both reported LAN_OPERATIONAL; the exact primary/backup split depends on configured priorities and HA negotiation.

Final Validation Checklist

Lessons from the Migration

The real work wasn't the install command itself. It was controlling the dependency chain: find the free disk, protect active services, move SEA to the partner, build and verify the image, install, reboot, then validate every I/O service before returning to normal operation.

The alternate-disk method also keeps the previous rootvg as old_rootvg, which simplifies post-upgrade validation and offers a recovery consideration, though it's not a guaranteed rollback mechanism on its own.

Finally, a passing ioslevel check is only one part of success. SEA state, NPIV login, Fibre Channel connectivity, client MPIO paths, network reachability, and tools like SSH/SFTP all need checking.

Known Issues Encountered

Two issues showed up after this migration that are worth flagging before you plan your own:

1. SCP stops working. After the OpenSSH update that comes with VIOS 4.1, plain scp transfers can fail. This is a known OpenSSH behavior change, not specific to VIOS — see IBM's support note, SCP no longer works after updating OpenSSH, for the cause and workaround.
2. Third-party software gets removed. viosupgrade performs a fresh install, so software like Zabbix agents or other third-party packages does not survive the migration and must be reinstalled afterward. This is the same behavior flagged under Additional software above — plan to reinstall and reconfigure any such software as part of your post-migration checklist.

References

Always check current official IBM documentation for prerequisites, supported combinations, and syntax specific to your environment:

• IBM VIOS documentation
• IBM viosupgrade documentation
• IBM PowerVM / SEA documentation

Related: If your VIOS environment is still running an earlier 3.1.4.x level, upgrade to 3.1.4.41 first. See the VIOS 3.1.4.21 to 3.1.4.41 upgrade guide before following the migration steps in this article.