Multibos saved my bacon!

A colleague of mine was planning to modify the max_xfer_size attribute on a couple of
FC adapters in one of his AIX LPARs. As he was describing his plan to me, I
asked him how he intended to back out of the change should the LPAR fail to
boot after the modifications. “But, what could
possibly go wrong?” he fired back. I advised him to use multibos to create a standby (backup)
instance of the AIX OS, just in case. He begrudgingly did so, just to keep me
happy.

The next day he told me the following
tale.

He had modified the FC adapters max_xfer_size attribute as planned.
First, checking the current values, for the attribute on both adapters.

aixlpar1
: / # lsattr -El fcs0 -a max_xfer_size

max_xfer_size
0x100000 Maximum Transfer Size True

aixlpar1
: / # lsattr -El fcs1 -a max_xfer_size

max_xfer_size
0x100000 Maximum Transfer Size True

He’d created a standby AIX instance before
making changes to the adapters. He also prevented multibos from changing the bootlist to the standby boot logical
volume (BLV).

Then he manually changed the LPARs boot
list to include the standby BLV.

aixlpar1
: / # bootlist -m normal hdisk2 blv=hd5
hdisk2 blv=bos_hd5

aixlpar1
: / # bootlist -m normal -o

hdisk2
blv=hd5 pathid=0

hdisk2
blv=hd5 pathid=1

hdisk2 blv=bos_hd5 pathid=0

hdisk2 blv=bos_hd5 pathid=1

He carefully recorded the bootlist output, just in case the boot
failed with new max_xfer_size values.
He could use the vdevice name and location
to manually select the standby BLV to start the system in an emergency.

The cause of the 554 hang appeared to be related
to the fact that the VIOS physical adapters needed their max_xfer_size value changed to the new value before the client LPAR
virtual fibre channel adapters were modified.