If you turn on Multiboot from within the SMS menu (as shown below), your LPAR will always boot into SMS, regardless of your AIX boot list and/or LPAR profile settings.

  

PowerPC Firmware

Version EM310_048

SMS 1.6 (c) Copyright IBM Corp. 2000,2005 All rights reserved.

-------------------------------------------------------------------------------

Multiboot

1. Select Install/Boot Device

2. Configure Boot Device Order

3. Multiboot Startup <ON>

-------------------------------------------------------------------------------

Navigation keys:

M = return to Main Menu

ESC key = return to previous screen X = eXit System Management Services

-------------------------------------------------------------------------------

Type menu item number and press Enter or select Navigation key:

 

If your LPAR always boots to the SMS menu, check the Multiboot Startup setting. If its set to ON, change it to OFF (as shown below). To access this option you must enter “5. Select Boot Options” from the main SMS menu.

 

PowerPC Firmware

Version EM310_048

SMS 1.6 (c) Copyright IBM Corp. 2000,2005 All rights reserved.

-------------------------------------------------------------------------------

Multiboot

1. Select Install/Boot Device

2. Configure Boot Device Order

3. Multiboot Startup <OFF>

-------------------------------------------------------------------------------

Navigation keys:

M = return to Main Menu

ESC key = return to previous screen X = eXit System Management Services

-------------------------------------------------------------------------------

Type menu item number and press Enter or select Navigation key:

 

Enabling Multiboot is only useful if you’re planning on dual-booting AIX and Linux within an LPAR. With Multiboot turned on, each time you reboot the LPAR, you are taken to SMS so you can choose which disk to boot from i.e. the AIX boot disk or the Linux boot disk. I’ve never come across anyone actually doing this in the commercial world. Mathew Davis (from IBM) wrote an article about dual booting AIX and Linux on pSeries back in 2005:

http://www.ibmsystemsmag.com/aix/aprilmay05/tipstechniques/6640p1.aspx

 

There can be other reasons why an LPAR always boots into SMS. The following link has some information on this:

 

http://www.aixmind.com/?tag=keeps-booting-to-sms

 

This IBM document explains how to select a boot disk from within the SMS menu.

 

http://www-01.ibm.com/support/docview.wss?rs=1209&context=SWG10&dc=DB520&q1=multiboot+SMS&uid=isg3T1011805&loc=en_US&cs=UTF-8&lang=en

 

 

Remember, if the disk doesn’t have a valid boot image, it won’t appear in the SMS menu as a boot device!

 

One way to check you have a boot device on your system is to run the ipl_varyon command from the AIX command line (before restarting your LPAR!):

 

# ipl_varyon -i

PVNAME          BOOT DEVICE     PVID                    VOLUME GROUP ID

hdisk0          YES             00f6048868b4e0ef0000    00f6048800004c00

 

If you don’t see a boot device on your system, perhaps someone has accidentally removed the boot record? Or maybe it was never created?

 

For example, in the commands that follow, I have “accidentally” run the ‘chpv –c’ command against my boot disk. This clears the boot record from the disk! The ipl_varyon command no longer shows hdisk0 as a bootable device.

 

Leaving the system in this state would prevent the system from booting!

 

To recreate the boot image, I run the bosboot command against hdisk0. Now ipl_varyon recognises hdisk0 as a bootable device again. Phew!

 

# chpv -c hdisk0

# ipl_varyon -i

PVNAME          BOOT DEVICE     PVID                    VOLUME GROUP ID

hdisk0          NO              00f6048868b4e0ef0000    00f6048800004c00

 

# bosboot -a -d /dev/hdisk0

bosboot: Boot image is 42689 512 byte blocks.

 

# ipl_varyon -i

PVNAME          BOOT DEVICE     PVID                    VOLUME GROUP ID

hdisk0          YES             00f6048868b4e0ef0000    00f6048800004c00

So, your root volume group is called old_rootvg not rootvg?

 

Wait……what!?

 

aixlpar1 : # lspv

hdisk0          00c342c68dfcbdfb             old_rootvg      active  < This is BAD!

hdisk1          00c342c6161c6b47             appvg           active

 

How did you end up in this situation? Did you reinstall AIX with some strange incantation or did some alternate disk activity go horribly wrong? Not sure? Me neither!

 

Fortunately the following tech-note and associated script can help.

 

http://www-01.ibm.com/support/docview.wss?uid=isg3T1000119

 

“Question

Rebuilding a Volume Group's Customized Device Database.

 

Answer

Run the script in this document when the ODM (Object Data Manager) entries for the root volume group are corrupted.”

 

“The script below assumes you are rebuilding the ODM definitions for the rootvg, which cannot be exported and then re-imported on a live system.

For most other volume groups, an export/import is the best way to clean up ODM problems.

If you need to rebuild ODM definitions for volume groups other than the rootvg, substitute appropriate values for PV and VG.”

So here’s the script:

#!/usr/bin/ksh
PV=`lslv -l hd5 | grep hdisk | head -1 | awk '{print $1}'`
VG=rootvg
lqueryvg -Lp $PV | awk '{ print $2 }' | while read LVname; do
odmdelete -q "name = $LVname" -o CuAt
odmdelete -q "name = $LVname" -o CuDv
odmdelete -q "value3 = $LVname" -o CuDvDr
odmdelete -q "dependency = $LVname" -o CuDep
done
odmdelete -q "name = $VG" -o CuAt
odmdelete -q "parent = $VG" -o CuDv
odmdelete -q "name = $VG" -o CuDv
odmdelete -q "name = $VG" -o CuDep
odmdelete -q "dependency = $VG" -o CuDep
if [ "$VG" = rootvg ]
then
odmdelete -q "value1 = 10" -o CuDvDr
else
odmdelete -q "value1 = $VG" -o CuDvDr
fi
odmdelete -q "value3 = $VG" -o CuDvDr
importvg -y $VG $PV # ignore lvaryoffvg errors
varyonvg $VG
synclvodm -Pv $VG # use -P only if running AIX V4.2.1 or later
savebase

 

Let’s execute the script to resolve this problem.

 

Note: Try this on a crash’n’burn system before unleashing it’s fury on a real AIX system (i.e. one that has users that depend on it!). Always take a mksysb backup before performing this type of activity.

 

aixlpar1 : /tmp # ksh -x fixmyrootvg.ksh

+ + lslv -l hd5

+ grep hdisk

+ head -1

+ awk {print $1}

PV=hdisk0

+ VG=rootvg

+ lqueryvg -Lp hdisk0

+ awk { print $2 }

+ read LVname

+ odmdelete -q name = hd5 -o CuAt

0518-307 odmdelete: 5 objects deleted.

+ odmdelete -q name = hd5 -o CuDv

0518-307 odmdelete: 1 objects deleted.

+ odmdelete -q value3 = hd5 -o CuDvDr

0518-307 odmdelete: 1 objects deleted.

+ odmdelete -q dependency = hd5 -o CuDep

0518-307 odmdelete: 1 objects deleted.

+ read LVname

+ odmdelete -q name = hd6 -o CuAt

0518-307 odmdelete: 4 objects deleted.

+ odmdelete -q name = hd6 -o CuDv

0518-307 odmdelete: 1 objects deleted.

+ odmdelete -q value3 = hd6 -o CuDvDr

0518-307 odmdelete: 1 objects deleted.

+ odmdelete -q dependency = hd6 -o CuDep

0518-307 odmdelete: 1 objects deleted.

+ read LVname

+ odmdelete -q name = hd8 -o CuAt

0518-307 odmdelete: 3 objects deleted.

+ odmdelete -q name = hd8 -o CuDv

0518-307 odmdelete: 1 objects deleted.

+ odmdelete -q value3 = hd8 -o CuDvDr

0518-307 odmdelete: 1 objects deleted.

+ odmdelete -q dependency = hd8 -o CuDep

0518-307 odmdelete: 1 objects deleted.

+ read LVname

+ odmdelete -q name = hd4 -o CuAt

0518-307 odmdelete: 5 objects deleted.

+ odmdelete -q name = hd4 -o CuDv

0518-307 odmdelete: 1 objects deleted.

+ odmdelete -q value3 = hd4 -o CuDvDr

0518-307 odmdelete: 1 objects deleted.

+ odmdelete -q dependency = hd4 -o CuDep

0518-307 odmdelete: 1 objects deleted.

+ read LVname

+ odmdelete -q name = hd2 -o CuAt

0518-307 odmdelete: 5 objects deleted.

+ odmdelete -q name = hd2 -o CuDv

0518-307 odmdelete: 1 objects deleted.

+ odmdelete -q value3 = hd2 -o CuDvDr

0518-307 odmdelete: 1 objects deleted.

+ odmdelete -q dependency = hd2 -o CuDep

0518-307 odmdelete: 1 objects deleted.

+ read LVname

+ odmdelete -q name = hd9var -o CuAt

0518-307 odmdelete: 5 objects deleted.

+ odmdelete -q name = hd9var -o CuDv

0518-307 odmdelete: 1 objects deleted.

+ odmdelete -q value3 = hd9var -o CuDvDr

0518-307 odmdelete: 1 objects deleted.

+ odmdelete -q dependency = hd9var -o CuDep

0518-307 odmdelete: 1 objects deleted.

+ read LVname

+ odmdelete -q name = hd3 -o CuAt

0518-307 odmdelete: 5 objects deleted.

+ odmdelete -q name = hd3 -o CuDv

0518-307 odmdelete: 1 objects deleted.

+ odmdelete -q value3 = hd3 -o CuDvDr

0518-307 odmdelete: 1 objects deleted.

+ odmdelete -q dependency = hd3 -o CuDep

0518-307 odmdelete: 1 objects deleted.

+ read LVname

+ odmdelete -q name = hd1 -o CuAt

0518-307 odmdelete: 5 objects deleted.

+ odmdelete -q name = hd1 -o CuDv

0518-307 odmdelete: 1 objects deleted.

+ odmdelete -q value3 = hd1 -o CuDvDr

0518-307 odmdelete: 1 objects deleted.

+ odmdelete -q dependency = hd1 -o CuDep

0518-307 odmdelete: 1 objects deleted.

+ read LVname

+ odmdelete -q name = hd10opt -o CuAt

0518-307 odmdelete: 5 objects deleted.

+ odmdelete -q name = hd10opt -o CuDv

0518-307 odmdelete: 1 objects deleted.

+ odmdelete -q value3 = hd10opt -o CuDvDr

0518-307 odmdelete: 1 objects deleted.

+ odmdelete -q dependency = hd10opt -o CuDep

0518-307 odmdelete: 1 objects deleted.

+ read LVname

+ odmdelete -q name = local -o CuAt

0518-307 odmdelete: 4 objects deleted.

+ odmdelete -q name = local -o CuDv

0518-307 odmdelete: 1 objects deleted.

+ odmdelete -q value3 = local -o CuDvDr

0518-307 odmdelete: 1 objects deleted.

+ odmdelete -q dependency = local -o CuDep

0518-307 odmdelete: 1 objects deleted.

+ read LVname

+ odmdelete -q name = hd7 -o CuAt

0518-307 odmdelete: 3 objects deleted.

+ odmdelete -q name = hd7 -o CuDv

0518-307 odmdelete: 1 objects deleted.

+ odmdelete -q value3 = hd7 -o CuDvDr

0518-307 odmdelete: 1 objects deleted.

+ odmdelete -q dependency = hd7 -o CuDep

0518-307 odmdelete: 1 objects deleted.

+ read LVname

+ odmdelete -q name = hd11admin -o CuAt

0518-307 odmdelete: 5 objects deleted.

+ odmdelete -q name = hd11admin -o CuDv

0518-307 odmdelete: 1 objects deleted.

+ odmdelete -q value3 = hd11admin -o CuDvDr

0518-307 odmdelete: 1 objects deleted.

+ odmdelete -q dependency = hd11admin -o CuDep

0518-307 odmdelete: 1 objects deleted.

+ read LVname

+ odmdelete -q name = rootvg -o CuAt

0518-307 odmdelete: 3 objects deleted.

+ odmdelete -q parent = rootvg -o CuDv

0518-307 odmdelete: 0 objects deleted.

+ odmdelete -q name = rootvg -o CuDv

0518-307 odmdelete: 1 objects deleted.

+ odmdelete -q name = rootvg -o CuDep

0518-307 odmdelete: 0 objects deleted.

+ odmdelete -q dependency = rootvg -o CuDep

0518-307 odmdelete: 0 objects deleted.

+ [ rootvg = rootvg ]

+ odmdelete -q value1 = 10 -o CuDvDr

0518-307 odmdelete: 1 objects deleted.

+ odmdelete -q value3 = rootvg -o CuDvDr

0518-307 odmdelete: 0 objects deleted.

+ importvg -y rootvg hdisk0

rootvg

0516-012 lvaryoffvg: Logical volume must be closed.  If the logical

        volume contains a filesystem, the umount command will close

        the LV device.

0516-942 varyoffvg: Unable to vary off volume group rootvg.

+ varyonvg rootvg

+ synclvodm -Pv rootvg

synclvodm: Physical volume data updated.

synclvodm: Logical volume hd5 updated.

synclvodm: Logical volume hd6 updated.

synclvodm: Logical volume hd8 updated.

synclvodm: Logical volume hd4 updated.

synclvodm: Logical volume hd2 updated.

synclvodm: Logical volume hd9var updated.

synclvodm: Logical volume hd3 updated.

synclvodm: Logical volume hd1 updated.

synclvodm: Logical volume hd10opt updated.

synclvodm: Logical volume hd7 updated.

synclvodm: Logical volume hd11admin updated.

+ savebase

 

Hey Presto! The root volume group is now named rootvg just the way we like it!

 

aixlpar1 : # lspv

hdisk0          00c342c68dfcbdfb                    rootvg          active

hdisk1          00c342c6161c6b47                    appvg            active

 

I NEVER thought this would happen! But, “NEVER SAY NEVER!”.  IBM just announced that AIX 5.3 can now run on POWER8.

 

http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca&infotype=an&appname=iSource&supplier=872&letternum=ENUSAP16-0152

 

As you’d expect, there are some caveats!

 

A special PTF (U86665.bff) provides POWER8 support on AIX  5.3 with the following limitations:

 

• The LPAR must be at AIX 5.3 TL12 SP9 (latest 5.3 release).
• The POWER8 LPAR will run in POWER6 compatibility mode and is limited to SMT2 mode. SMT2 mode results in some capacity loss compared to SMT4/SMT8 mode. IBM publishes SMT2 rPerf values that can be used to quantify Power8 SMT2 capacity.
• AIX 5.3 POWER8 LPARs only support Virtual I/O configurations: vSCSI, NIPV, VLAN.
• LPM is supported.

 

The only supported AIX 5.3 POWER8 installation methods are:

 

• mksysb – First perform an in place update to a supported (P5/P6/P7) AIX 5.3 TL12 SP9 LPAR with PTF U866665. Standard mksysb command can then be used to capture a P8 capable mksysb image. The mksysb image can then be used to install POEWR8 LPARs
• NIM – An AIX 5.3 TL12 SP9 NIM environment must be updated to support POWER8. An AIX 5.3 TL12 SP9 NIM lpp_source must be updated to include PTF U866665. A NIM SPOT must then be created to utilize the updated lpp_source.

 

All POWER8 systems are supported with the following restrictions:

 

• POWER8 system must be at 840 firmware level.
• POWER8 LPAR must be served by a 2.2.4.10 VIOS.

 

Other restrictions:

 

• Remote restart is not supported with POWER8 5.3 LPARs
• POWER8 AIX 5.3 LPARs are not supported with a VIOS using Shared Storage Pools.

 

 

I tested this in my lab and it all worked as expected. I installed the PTF on an existing AIX 5.3 LPAR on a POWER7 750 and rebooted the partition.

 

[root@53gibbo]/ # lspv

hdisk0          00f603cdcd9ba6de                    rootvg          active

 

[root@53gibbo]/ # oslevel -s

5300-12-09-1341

 

[root@53gibbo]/ # lsconf | more

System Model: IBM,8233-E8B

Machine Serial Number: 1003CDP

Processor Type: PowerPC_POWER7

Processor Implementation Mode: POWER 6

Processor Version: PV_6_Compat

Number Of Processors: 2

Processor Clock Speed: 3550 MHz

CPU Type: 64-bit

Kernel Type: 64-bit

LPAR Info: 3 53gibbo

Memory Size: 2048 MB

Good Memory Size: 2048 MB

Platform Firmware level: AL730_142

Firmware Version: IBM,AL730_142

 

[root@53gibbo]/tmp/cg/aix53p8 # inutoc .

[root@53gibbo]/tmp/cg/aix53p8 # ls -ltr

total 35808

-rw-r-----    1 root     system      8994816 Feb  8 09:35 U866665.bff

-rw-r-----    1 root     system      8994816 Feb  8 09:37 bos.mp64.5.3.12.10.U

-rw-r--r--    1 root     system       328592 Feb  8 09:37 .toc

 

[root@53gibbo]/tmp/cg/aix53p8 # update_all -d .

install_all_updates: Initializing system parameters.

install_all_updates: Log file is /var/adm/ras/install_all_updates.log

install_all_updates: Checking for updated install utilities on media.

install_all_updates: Processing media.

install_all_updates: Generating list of updatable installp filesets.

install_all_updates: The following filesets have been selected as updates

to currently installed software:

 

   bos.mp64 5.3.12.10

 

   << End of Fileset List >>

 

install_all_updates: Performing installp update.

+-----------------------------------------------------------------------------+

                    Pre-installation Verification...

+-----------------------------------------------------------------------------+

Verifying selections...done

Verifying requisites...done

Results...

 

SUCCESSES

---------

  Filesets listed in this section passed pre-installation verification

  and will be installed.

 

  Selected Filesets

  -----------------

  bos.mp64 5.3.12.10                          # Base Operating System 64-bit...

 

  << End of Success Section >>

 

+-----------------------------------------------------------------------------+

                   BUILDDATE Verification ...

+-----------------------------------------------------------------------------+

Verifying build dates...done

FILESET STATISTICS

------------------

    1  Selected to be installed, of which:

        1  Passed pre-installation verification

  ----

    1  Total to be installed

 

installp:  bosboot verification starting...

installp:  bosboot verification completed.

+-----------------------------------------------------------------------------+

                         Installing Software...

+-----------------------------------------------------------------------------+

 

installp: APPLYING software for:

        bos.mp64 5.3.12.10

 

 

. . . . . << Copyright notice for bos.mp64 >> . . . . . . .

 Licensed Materials - Property of IBM

 

 5765G0399

   Copyright International Business Machines Corp. 2000, 2015.

   Copyright William Erik Baxter, 2004.

   Copyright RSA Data Security, Inc. 1991-1992.

 

 All rights reserved.

 US Government Users Restricted Rights - Use, duplication or disclosure

 restricted by GSA ADP Schedule Contract with IBM Corp.

. . . . . << End of copyright notice for bos.mp64 >>. . . .

 

Finished processing all filesets.  (Total time:  3 secs).

 

installp:  bosboot verification starting...

installp:  bosboot verification completed.

installp:  bosboot process starting...

 

bosboot: Boot image is 45802 512 byte blocks.

0503-292 This update will not fully take effect until after a

        system reboot.

 

    * * *  A T T E N T I O N  * * *

    System boot image has been updated. You should reboot the

    system as soon as possible to properly integrate the changes

    and to avoid disruption of current functionality.

 

installp:  bosboot process completed.

+-----------------------------------------------------------------------------+

                                Summaries:

+-----------------------------------------------------------------------------+

 

Installation Summary

--------------------

Name                        Level           Part        Event       Result

-------------------------------------------------------------------------------

bos.mp64                    5.3.12.10       USR         APPLY       SUCCESS

 

    * * *  A T T E N T I O N  * * *

    System boot image has been updated. You must reboot the system

    after install_all_updates completes to properly integrate the updates.

 

install_all_updates: Checking for recommended maintenance level 5300-12.

install_all_updates: Executing /usr/bin/oslevel -rf, Result = 5300-12

install_all_updates: Verification completed.

install_all_updates: Log file is /var/adm/ras/install_all_updates.log

install_all_updates: Result = SUCCESS

 

[root@53gibbo]/tmp/cg/aix53p8 # oslevel -s

5300-12-09-1341

 

[root@53gibbo]/tmp/cg/aix53p8 # lslpp -l bos.mp64

  Fileset                      Level  State      Description

  ----------------------------------------------------------------------------

Path: /usr/lib/objrepos

  bos.mp64                 5.3.12.10  APPLIED    Base Operating System 64-bit

                                                 Multiprocessor Runtime

 

Path: /etc/objrepos

  bos.mp64                  5.3.11.2  COMMITTED  Base Operating System 64-bit

                                                 Multiprocessor Runtime

[root@53gibbo]/tmp/cg/aix53p8 # at now

shutdown –Fr

 

My POWER8 system was an S824 running the latest firmware (840_056), with VIOS running the latest code (2.2.4.10) and the latest HMC code (8.4).

 

p8vio1:/home/padmin# lsconf | head -20

System Model: IBM,8286-42A

Machine Serial Number: 214F55V

Processor Type: PowerPC_POWER8

Processor Implementation Mode: POWER 7

Processor Version: PV_7_Compat

Number Of Processors: 2

Processor Clock Speed: 3525 MHz

CPU Type: 64-bit

Kernel Type: 64-bit

LPAR Info: 101 82861_vio1

Memory Size: 18432 MB

Good Memory Size: 18432 MB

Platform Firmware level: SV840_056

Firmware Version: IBM,FW840.00 (SV840_056)

 

On my NIM master I created a new lppsource and SPOT for AIX 5.3 TL12 SP9 and included the required PTF U86665.

 

# lsnim -t spot | grep 53

spotAIX53TL12SP9     resources       spot

 

# lsnim -t lpp_source | grep 53

AIX53TL12SP9             resources       lpp_source

 

# nim -o showres spotAIX53TL12SP9 | grep bos.mp64

  bos.mp64                 5.3.12.10    C     F    Base Operating System 64-bit

 

# nim -o showres AIX53TL12SP9_P8 | grep bos.mp64

  bos.mp64                    5.3.11.2                   I  b usr,root

  bos.mp64                    5.3.12.9                   S  b usr

  bos.mp64                    5.3.12.10                  S  b usr

 

I took a mksysb on the 5.3 LPAR to my NIM master. I then used the mksysb to perform an NIM mksysb install (restore) to a new partition on the S824. This worked flawlessly. The partition was configured in POWER6 mode with SMT2 only.

 

[root@53gibbo]/ # oslevel -s

5300-12-09-1341

 

[root@53gibbo]/ # lsconf | head -10

System Model: IBM,8286-42A

Machine Serial Number: 214F55V

Processor Type: PowerPC_POWER8

Processor Implementation Mode: POWER 6

Processor Version: PV_6_Compat

Number Of Processors: 2

Processor Clock Speed: 3525 MHz

CPU Type: 64-bit

Kernel Type: 64-bit

LPAR Info: 2 53gibbo

Memory Size: 2048 MB

Good Memory Size: 2048 MB

Platform Firmware level: SV840_056

Firmware Version: IBM,FW840.00 (SV840_056)

Console Login: enable

Auto Restart: true

Full Core: false

 

[root@53gibbo]/ # smtctl

 

This system is SMT capable.

SMT is currently enabled.

SMT boot mode is not set.

SMT threads are bound to the same virtual processor.

 

proc0 has 2 SMT threads.

Bind processor 0 is bound with proc0

Bind processor 1 is bound with proc0

 

 

proc2 has 2 SMT threads.

Bind processor 2 is bound with proc2

Bind processor 3 is bound with proc2

 

[root@53gibbo]/ # lparstat -i

Node Name                                  : 53gibbo

Partition Name                             : 53gibbo

Partition Number                           : 2

Type                                       : Shared-SMT

Mode                                       : Uncapped

Entitled Capacity                          : 0.20

Partition Group-ID                         : 32770

Shared Pool ID                             : 0

Online Virtual CPUs                        : 2

Maximum Virtual CPUs                       : 4

Minimum Virtual CPUs                       : 1

Online Memory                              : 2048 MB

Maximum Memory                             : 4096 MB

Minimum Memory                             : 1024 MB

Variable Capacity Weight                   : 128

Minimum Capacity                           : 0.10

Maximum Capacity                           : 4.00

Capacity Increment                         : 0.01

Maximum Physical CPUs in system            : 24

Active Physical CPUs in system             : 24

Active CPUs in Pool                        : 14

Shared Physical CPUs in system             : 14

Maximum Capacity of Pool                   : 1400

Entitled Capacity of Pool                  : 1160

Unallocated Capacity                       : 0.00

Physical CPU Percentage                    : 10.00%

Unallocated Weight                         : 0

Desired Virtual CPUs                       : 2

Desired Memory                             : 2048 MB

Desired Variable Capacity Weight           : 128

Desired Capacity                           : 0.20

 

The example above shows you how to migrate an AIX 5.3 system using NIM and mksysb. But you don’t have to do this, as LPM is fully supported. The migration effort for many customers is as easy as kicking off an LPM operation to move their (updated) AIX 5.3 partitions from their older Power servers to POWER8. Easy!

 

So I guess customers that still need to run AIX 5.3 on POWER8 now have an alternative to AIX 5.3 Versioned WPARs. But please keep in mind the performance and support considerations when making your decision.

Additional README information available here:

https://www.ibm.com/developerworks/community/blogs/cgaix/resource/U866665README.pdf

 

 

IBM recently announced some significant changes to their ‘AIX Release and Service Delivery’ strategy. Starting February 2011, the following changes will apply for both AIX 6 and AIX 7.

               

•          Three years of support for each Technology Level (TL).

•          A single Technology Level per AIX version, per year.

•          Service Packs will be released approximately 4 times per year per Technology Level.

 

Some of the benefits of the new strategy are:

 

• Longer support for Technology Levels.

–      More closely matches client deployment requirements.

 

·         Single Technology Level per year, per version, and about one Service Pack per quarter.

–      Fewer updates reduce administrative workload.

 

·         New hardware is supported on prior Technology Levels.

–      Easier integration of new hardware into existing environments.

 

You can review the official presentation and details here. I particularly like this FAQ from the presentation.

 

Q: Why doesn’t the new strategy include AIX V5.3?

A: AIX V5.3 is nearing end of life with the End of Marketing for AIX V5.3 set for April 2011

 

So if you are on AIX 5.3, start planning a migration to AIX 7.1 (or at least AIX 6.1), NOW! I’ve provided some further information from the presentation below.

 

 

 

Longer Support for each Technology Level

The 2011 Release Strategy extends the support for each Technology Level for up to three years from the introduction of the Technology Level. This means that clients with a Software Maintenance Agreement for the AIX OS will receive IBM defect support during that two year period without having to move up to the latest Technology Level update.

For example, a Technology Level introduced in the second half of 2010 will be supported though the second half of 2013. Since each Technology Level will be supported for three years and IBM plans to release one Technology Level per year, IBM eventually will support up to six Technology Levels for each AIX release.  Please note that due to minor variations in release dates, some Technology Levels will be supported for slightly more that three years and some will be supported for slightly less than three years. A three year service life for each Technology Level is an objective, not an absolute limit.

 

Fewer Technology Levels and Fewer Service Packs

Historically, new Technology Levels were the only way to deliver new hardware support to clients. Since 2007, we have supported most new hardware on previous Technology Levels via a service pack. Since this new approach to supporting new hardware has been well proven with the introduction of POWER7 in 2010, we decided to eliminate the “Spring” Technology Level which reduces the number of updates clients have to deal with. The number of Service Packs has been about 5 per year and we want to reduce this number to about once per quarter.

 

 

 

Between Technology Level releases, clients maintain their AIX operating systems by installing Service Packs (SP) or Interim Fixes for the entire support life of the Technology Level update. Service Packs are also used to provide support for newly released hardware.

The release dates and frequency of Service Packs are variable due to many factors. including new Technology Level releases, new hardware introduction and the need to deliver software fixes.

 

In the past IBM delivered new Service Packs about every eight to twelve weeks or about five to eight times per year per Technology Level. With the 2011 release strategy, IBM intends to reduce the number of Service Packs released per year, per AIX release to about four. As stated earlier, there are many factors that drive the release of a Service Pack, so releasing four Service Packs per year, per Technology Level represents a goal and objective, but not an absolute limit.

 

Note that new Technology Levels are almost always accompanied very closely by the first Service Pack for that new Technology Level. This first Service Pack includes fixes to problems that are discovered between the time the new Technology Level is released to manufacturing for the media to be replicated and the time the new Technology Level is actually available to clients.

 

Summary

The providers of all software, including platform software such as the AIX operating system, must balance the client’s need for stability against the need to enhance the software to provide new functionality. The changes introduced with the AIX OS Release and Service Strategy of 2011 balances those two conflicting goals to help provide our clients with significant improvements in the manageability of the AIX operating system.

The increased service life, better manageability and support for new hardware on older fix levels provided by the new strategy are in direct response to our client’s requirements.

As stated earlier, this new strategy represents goals and objectives of IBM and is subject to change. Our clients understand that substantial changes such as this new strategy are an indication of the commitment that IBM has to improving the market leading capabilities of the AIX operating system.

 

For more information and best practices please refer to:

 

https://www14.software.ibm.com/webapp/set2/sas/f/best/home.html

 

 

 

# fcstat –D fcs0

FIBRE CHANNEL STATISTICS REPORT: fcs0

…

 FC SCSI Adapter Driver Queue Statistics

    Number of active commands:   0

    High water mark of active commands:   17

    Number of pending commands:   0

    High water mark of pending commands:   1

    Number of commands in the Adapter Driver Held off queue:  0

    High water mark of number of commands in the Adapter Driver Held off queue:  0

…

 

The –D is a new option on fcstat, not yet documented in the man pages.

 

Set num_cmd_elems to >= high water mark of active commands or the default, whichever is greater.

 

# chdev –l fcs0 –a num_cmd_elems=4096 –a max_xfer_size=0x200000 –P

; requires a reboot

 

Thanks to Dan Braden (IBM ATS) for this tip. 

 

Today, IBM announced AIX version 7.  http://www-03.ibm.com/systems/power/software/aix/v71/preview.html

Several new features were mentioned in the launch, but there were two new features that I found particularly interesting:

 

- AIX 5.2 WPARs for AIX 7

- Cluster Aware AIX

 

I thought I would briefly describe each feature in this post.

 

AIX 5.2 WPARs for AIX 7

 

In AIX version 7, administrators will now have the capability to create Workload Partitions (WPARs) that can run AIX 5.2, inside an AIX 7 operating system instance. This will be supported on the POWER7 server platform.  This is pretty cool. IBM have done this to allow some customers, that are unable to migrate to later generations of AIX and Power, to move to POWER7 whilst keeping their legacy AIX 5.2 systems operational. So for those clients that MUST stay on AIX 5.2 (for various reasons such as Application support) but would like to run their systems on POWER7, this feature may be very attractive. It will help to reduce the effort required when consolidating older AIX 5.2 systems onto newer hardware. It may also reduce some of the risk associated with migrating applications from one version of the AIX operating system to another.

 

To migrate an existing AIX 5.2 system to an AIX 7 WPAR, administrators will first need to take a mksysb of the existing system. Then they can simply restore the mksysb image inside the AIX 7 WPAR. IBM will also offer limited defect and how-to support for the AIX 5.2 operating system in an AIX 7 WPAR. These WPARs can, of course, be managed via IBM Systems Director with the Workload Partitions Manager plug-in.

 

The following figure provides a visualization of how these AIX 5.2 systems will fit into an AIX 7 WPAR. The WPARs in blue are native AIX 7 WPARs, while the WPARs in orange are AIX 5.2 WPARs running in the same AIX 7 instance. Pretty amazing really!

I can only speculate as to what other versions of AIX will be supported in this manner in the future. Just imagine an AIX 5.3 WPAR inside AIX7?

 

 

Cluster Aware AIX

 

Another very interesting feature of AIX 7 is a new technology known as “Cluster Aware AIX”. Believe it or not, administrators will now be able to create a cluster of AIX systems using features of the new AIX 7 kernel. IBM have introduced this “in built” clustering to the AIX OS in order to simplify the configuration and management of highly available clusters. This new AIX clustering has been designed to allow for:

 

- The easy creation of clusters of AIX instances for scale-out computing or high availability.

- Significantly simplify cluster configuration, construction, and maintenance.
- Improve availability by reducing the time to discover failures.

-  Capabilities such as common device naming to help simplify administration.

- Built in event management and monitoring.

- A foundation for future AIX capabilities and the next generation of PowerHA SystemMirror.

 

This does not replace PowerHA but it does change the way in which AIX traditionally integrates with cluster software like HACMP and PowerHA. A lot of the HA cluster functionality is now available in the AIX 7 kernel itself. However, the mature RSCT technology is still a component of the AIX and PowerHA configuration. I’m looking forward to reading more about this new technology and it’s capabilities.

 

These are just two of the many features introduced in AIX 7. I’m eagerly looking forward to what these features and others mean for the future of the AIX operating system. It’s exciting to watch this operating system grow and strengthen over time. I can’t wait to get my hands on an AIX 7 system so that I can trial these new features.

 

And speaking of trialing AIX 7, there is good news. IBM plan on running another AIX Open Beta program for AIX 7 mid 2010. Just as they did with AIX Version 6, customers will be given the opportunity to download a beta version of AIX 7 and trial it on their own systems in their own environment. This is very exciting and I’m really looking forward to it.

 

I encourage you to read the official AIX 7 announcement to learn more about the future of the AIX operating system and what it can do for you and your organization…..for many years to come!

 

There are two new HMC (V7.7.3.0) commands that can force a client Virtual Fibre Channel adapter to log into a SAN. This should make the life of the AIX and SAN administrator easier, as they will no longer need to install AIX in order for the new VFC adapters to log into the SAN. Although there was an unsupported method* for doing this already (see links below). Nor will the SAN admins need to “blind” zone the WWPNs.

 

There was some indication of this in the latest VIOS FP readme:

 

https://www-304.ibm.com/support/docview.wss?rs=0&uid=isg400000693

 

·         Enabled SAN login from VIOS

 

And there was this:

 

IZ95569: ENABLE SAN LOGIN FROM VIOS FOR IMPROVED UABILITY

https://www-304.ibm.com/support/docview.wss?uid=isg1IZ95569

 

Problem summary

·    Customer will be able to instruct the VIOS to login to the SAN

·    for a given WWPN on a given virtual adapter to allow the

·    customer to see the WWPN in SAN management tools and easing

·    the task of configuring new NPIV client

·    partitions.

·          

Problem conclusion

·    add commands to VIOS manager interface to allow the HMC to

·    login, logout and query virtual adapters.

 

And finally this:

 

http://www-304.ibm.com/webapp/set2/sas/f/hmcl/power7/v7730.Readme.html#enhance7730

The new lsnportlogin and chnportlogin commands on the 7.730 HMC provide the ability to utilize the new function in the VIOS. From the Readme:

Added the chnportlogin and lsnportlogin commands.

 

1.  The chnportlogin command allows you to perform N Port login and logout operations for virtual fibre channel client adapters that are configured in a partition or a partition profile. Use this command to help you in zoning WWPNs on a Storage Area Network (SAN). A login operation activates all inactive WWPNs, including the second WWPN in the pair assigned to each virtual fibre channel client adapter. This feature is particularly useful for Logical Partition Migration. A logout operation deactivates all WWPNs not in use. A successful login of a virtual fibre channel adapter requires that the corresponding virtual fiber channel server adapter must exist and that it must be mapped.

 

2.  The lsnportlogin command also allows you to list WWPN login status information for virtual fibre channel client adapters configured in partitions or partition profiles.

 

I found a lot of this information on the IBM developerWorks PowerVM forum:

 

http://www.ibm.com/developerworks/forums/thread.jspa?threadID=388796

 

Thanks to http://twitter.com/Kristijan for pointing me in the direction of the PowerVM forum.

 

Here’s an example of using the lsnportlogin command on one of my systems:

 

hscroot@HMC1:~>  lsnportlogin -m  770-1-Rack_D191 --filter "profile_names=normal"

lpar_name=nim1,lpar_id=3,profile_name=normal,slot_num=32,wwpn=c050760405f0000c,wwpn_status=0

lpar_name=nim1,lpar_id=3,profile_name=normal,slot_num=32,wwpn=c050760405f0000d,wwpn_status=0

lpar_name=nim1,lpar_id=3,profile_name=normal,slot_num=33,wwpn=c050760405f0000e,wwpn_status=0

lpar_name=nim1,lpar_id=3,profile_name=normal,slot_num=33,wwpn=c050760405f0000f,wwpn_status=0

lpar_name=nim1,lpar_id=3,profile_name=normal,slot_num=30,wwpn=c050760405f00000,wwpn_status=0

lpar_name=nim1,lpar_id=3,profile_name=normal,slot_num=30,wwpn=c050760405f00001,wwpn_status=0

lpar_name=nim1,lpar_id=3,profile_name=normal,slot_num=31,wwpn=c050760405f00002,wwpn_status=0

lpar_name=nim1,lpar_id=3,profile_name=normal,slot_num=31,wwpn=c050760405f00003,wwpn_status=0

lpar_name=aix01adm,lpar_id=4,profile_name=normal,slot_num=32,wwpn=c050760405f00004,wwpn_status=0

lpar_name=aix01adm,lpar_id=4,profile_name=normal,slot_num=32,wwpn=c050760405f00005,wwpn_status=0

lpar_name=aix01adm,lpar_id=4,profile_name=normal,slot_num=33,wwpn=c050760405f00006,wwpn_status=0

lpar_name=aix01adm,lpar_id=4,profile_name=normal,slot_num=33,wwpn=c050760405f00007,wwpn_status=0

lpar_name=aix01adm,lpar_id=4,profile_name=normal,slot_num=30,wwpn=c050760405f00008,wwpn_status=0

lpar_name=aix01adm,lpar_id=4,profile_name=normal,slot_num=30,wwpn=c050760405f00009,wwpn_status=0

lpar_name=aix01adm,lpar_id=4,profile_name=normal,slot_num=31,wwpn=c050760405f0000a,wwpn_status=0

lpar_name=aix01adm,lpar_id=4,profile_name=normal,slot_num=31,wwpn=c050760405f0000b,wwpn_status=0

 

 

              Descriptions of selected command attributes:

                   wwpn_status

                        The WWPN status.  Possible values are:

                        0 - WWPN is not activated

                        1 - WWPN is activated

                        2 - WWPN status is unknown

 

Some related links:

 

lsnportlogin

http://publib.boulder.ibm.com/infocenter/powersys/v3r1m5/topic/p7edm/lsnportlogin.html

 

chnportlogin

http://publib.boulder.ibm.com/infocenter/powersys/v3r1m5/topic/p7edm/chnportlogin.html

 

*How to force a vfc-client device to log in to the SAN (The OLD way)!

https://www.ibm.com/developerworks/wikis/display/virtualization/vfclogin

 

How to Capture SAN Boot Debug for Virtual I/O Server and AIX on P6 Systems

https://www-304.ibm.com/support/docview.wss?uid=isg3T1012199

http://unixadmin.free.fr/?p=245

 

Disk path design for AIX including SAN zoning

http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101914

 

 

A new HMC & Firmware 840 feature allows LPM in a dual VIOS configuration when one VIOS is failed. Previously, LPM was not allowed if one of the source VIOS (in a dual VIOS configuration) was in a failed state. Both VIOSes had to be operational to perform LPM. The new support allows the HMC to cache adapter configuration from both VIOSes. Whenever changes are made to the configuration, the cached information will be updated on the HMC. If one VIOS is failed, instead of querying the failed VIOS, the HMC cache is used instead to create the new configuration on the target VIOS. This support was needed to cover the situation where there’s failed hardware which is causing an outage on the VIOS and requires a disruptive repair action. This new feature is enabled using a server wide HMC setting to enable the automatic caching of VIOS configuration details.

 

You can enable/disable this setting using the new Enhanced+ HMC interface. You’ll find it under General Properties of the Managed System (Server).

 

 

You can also enabled/disable this feature using the HMC command line, with migrlpar.

 

$ migrlpar -o set -m <managed system> -r sys -i “allow_inactive_source_storage_vios=1/0”

$ lslparmigr -r sys -m <managed system> -F allow_inactive_source_storage_vios

 

Whilst we’re on the subject of new HMC features; you may have heard that it is now possible to disable LPM on a per partition basis. You read more about this feature here:

 

https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Power%20Systems/page/HMC%20per-partition%20disablement%20of%20Live%20Partition%20Mobility%20%28LPM%29

 

This feature can be enabled/disabled, per partition, using the HMC Enhanced+ interface. You’ll find this under General Properties of a Partition.

 

 

You can also use the HMC command, chsyscfg, to toggle this setting.

 

$ chsyscfg -r lpar -m Server-8286-42A-SN991F99V -i "name=RHEL_6_5,migration_disabled=1"

$ lssyscfg -r lpar -m Server-8286-42A-SN991F99V -F name,migration_disabled

 

Useful links and additional information.

 

Live Partition Mobility (LPM) improvements in PowerVM 2.2.4

https://www.ibm.com/developerworks/community/wikis/home?lang=en_us#!/wiki/Power%20Systems/page/Live%20Partition%20Mobility%20%28LPM%29%20improvements%20in%20PowerVM%202.2.4

 

HMC V8 R8.4.0 Command Line specification

https://www-304.ibm.com/webapp/set2/sas/f/hmcl/power8/hmc_man_8.4.0.pdf

 

HMC Manual Reference Pages  - MIGRLPAR (1)

https://www.ibm.com/support/knowledgecenter/HW4P4/p8edm/migrlpar.html

 

IBM Power Systems HMC Implementation and Usage Guide

http://www.redbooks.ibm.com/redpieces/pdfs/sg248334.pdf

 

Hardware Management Console - Related technical information

https://www-304.ibm.com/webapp/set2/sas/f/hmcl/resources.html