I do not know for how many, but for a lot of us VIOS servers (at least two per a frame) deliver disks to their clients (partitions/lpars) which use them as the
rootvg disks. Upgrading
VIOS it is easy to forget about this fact which ends in the client partitions demise.
What I am referring to, is the fact that to activate server OS upgrade, you have to reboot it and as the result it’s clients will loose the access to disks provided by the VIOS server being rebooted! Its partitionsr
rootvg will become
stale as Limburger cheese, well almost.
If you still did not recognize this fact, and proceed to upgrade of the second VIOS then guess what is going to happen a few seconds later after this VIOS gets its reboot? A pure stink!
At this time, all client partitions (lpar) smell really bad and so do you not to mentioned you may perspire more then before the upgrade ….. But, do not worry – you have a good company! I almost did it to myself today.
So what should you do after reboot of the first VIOS server. Well, start with verifying that its OS level is what you wanted – execute the
ioslevel command. Satisfied with the results, login to its each and every client partition and establish what dump device (primary/secondary) is delivered by the just upgraded VIOS – disable the appropriate dump device (if in doubts, disable both).
To disable the
Primary dump device:
# sysdumpdev -P -p /dev/sysdumpnull
To disable the
Secondary dump device:
# sysdumpdev -P -s /dev/sysdumpnull
Next, execute the following few commands:
# lsvg -p rootvg # varyonvg -bu rootvg # varyonvg rootvg # lsvg -p rootvg
Wait for the
syncvg processes to do their job and at the end enable the
# sysdumpdev -P -p /dev/dump0
# sysdumpdev -P -s /dev/dump1
By the way, remember that mine and your
dump devices may not be called the same.
But what will happen if you attempt to
0516-1774 varyonvg: Cannot varyon volume group with an active dump device on a missing physical volume. Use sysdumpdev to temporarily replace the dump device with /dev/sysdumpnull and try again.