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

 

FYI.

There are new options for /etc/resolv.conf in AIX 6.1 (not in 5.3):

...
timeout
        Enables you to specify the initial timeout for a query to a nameserver. The default value is five seconds. The maximum value is 30 seconds. For
        the second and successive rounds of queries, the resolver doubles the initial timeout and is divided by the number of nameservers in the
        resolv.conf file.

attempts
        Enables you to specify how many queries the resolver should send to each nameserver in the resolv.conf file before it stops execution. The
        default value is 2. The maximum value is 5.

rotate
        Enables the resolver to use all the nameservers in the resolv.conf file, not just the first one.
...

New SEA thread tuning parameters with VIOS level 2.2.2.2

 

• Number of threads (nthreads)

Specifies the number of threads in threaded mode, where the value of the thread parameter is 1. This value applies only when the thread mode is enabled. The nthreads attribute can be set to any value between 1 and 128. The default value is 7.

 

• Queue size (queue_size)

Specifies the queue size for the Shared Ethernet Adapter (SEA) threads in threaded mode where the value of the thread parameter is 1. This attribute indicates the number of packets that can be accommodated in each thread queue. This value applies only when the thread mode is enabled. When you change this value, the change does not take effect until the system restarts. The queue_size attribute can be set to any value between 2 and 65535. The default value is 8192.

 

• Hash algorithms (hash_algo)

Specifies the hash algorithm that is used to assign connections to Shared Ethernet Adapter (SEA) threads in threaded mode, where the value of the thread parameter is 1. When the hash_algo parameter is set to 0 (the default), an addition operation of the source and destination Media Access Control (MAC) addresses, IP addresses, and port numbers is done. When the hash_algo parameter is set to 1, a murmur3 hash function is done instead of an addition operation. The murmur3 hash function is slower, but it achieves better distribution. This value applies only when the thread mode is enabled.

 

$ lsdev -dev ent6 -attr

attribute     value    description                                                        user_settable

 

accounting    enabled  Enable per-client accounting of network statistics                 True

ctl_chan               Control Channel adapter for SEA failover                           True

gvrp          no       Enable GARP VLAN Registration Protocol (GVRP)                      True

ha_mode       disabled High Availability Mode                                             True

hash_algo     0        Hash algorithm used to select a SEA thread                         True

jumbo_frames  no       Enable Gigabit Ethernet Jumbo Frames                               True

large_receive no       Enable receive TCP segment aggregation                             True

largesend     0        Enable Hardware Transmit TCP Resegmentation                        True

lldpsvc       no       Enable IEEE 802.1qbg services                                      True

netaddr       0        Address to ping                                                    True

nthreads      7        Number of SEA threads in Thread mode                               True

pvid          50       PVID to use for the SEA device                                     True

pvid_adapter  ent4     Default virtual adapter to use for non-VLAN-tagged packets         True

qos_mode      disabled N/A                                                                True

queue_size    8192     Queue size for a SEA thread                                        True

real_adapter  ent0     Physical adapter associated with the SEA                           True

thread        1        Thread mode enabled (1) or disabled (0)                            True

virt_adapters ent4     List of virtual adapters associated with the SEA (comma separated) True

 

# lsattr -Rl ent6 -a hash_algo

0...1 (+1)

 

# lsattr -Rl ent6 -a nthreads

1...128 (+1)

 

# lsattr -Rl ent6 -a queue_size

2...65535 (+1)

 

http://pic.dhe.ibm.com/infocenter/powersys/v3r1m5/index.jsp?topic=%2Fp7hb1%2Fiphb1_vios_managing_sea_attr.htm

 

 

New LPM tuning parameters with VIOS level 2.2.2.2.

 

A new pseudo device is available to support Live Partition Mobility performance tuning.

 

• The pseudo device vioslpm0 is created by default when VIO server version 2.2.2.0 or higher is installed.
• Device attributes for vioslpm0 can be used to control live partition mobility operations.
• Use normal lsdev/chdev padmin commands to query/change attributes.

 

$ lsdev –dev vioslpm0 –attr

$ chdev –dev vioslpm0 –attr cfg_msp_ops=5

 

$ lsdev -dev vioslpm0 -attr

attribute       value description                                                 user_settable

 

cfg_msp_lpm_ops 8     Configured number of concurrent LPM operations for this MSP True

concurrency_lvl 3     Concurrency level                                           True

lpm_msnap_succ  1     Create mini-snap for successful migrations                  True

max_lpm_vasi    1     Maximum number of VASI adapters used for LPM operations     False

max_vasi_ops    8     Maximum number of concurrent LPM operations per VASI        False

tcp_port_high   0     TCP highest ephemeral port                                  True

tcp_port_low    0     TCP lowest ephemeral port                                   True

 

Pseudodevice attributes and definition
Attribute	Value	Description	User modifiable
cfg_msp_lpm_ops	8	Number of concurrent partition mobility operations for the mover service partition	True
concurrency_lvl	3	Concurrency level	True
lpm_msnap_succ	1	Create a mini-snap (when a migration ends, the set of information related to a specific migration, that is gathered and packed on each mover service partition involved in the migration), for successful migrations	True
max_lpm_vasi	1	Maximum number of Virtual Asynchronous Services Interface (VASI) adapters used for partition mobility operations	False
max_vasi_ops	8	Maximum number of concurrent partition mobility operations per VASI	False
tcp_port_high	0	TCP highest ephemeral port	True
tcp_port_low	0	TCP lowest ephemeral port	True

 

http://pic.dhe.ibm.com/infocenter/powersys/v3r1m5/topic/p7hc3/iphc3vioslpmpseudo.htm

 

New features of the migrlpar command with VIOS level 2.2.2.2.

 

• Specify fibre channel ports using vios_fc_port_name. Run the lslparmigr command to show a list of available slot IDs for a VIOS partition. Run the migrlpar command to accomplish the following tasks:

 

• Specify virtual slot IDs for one or more virtual adapter mappings.
• Validate the specified slot IDs.
• Note: You can specify the port name of the Fibre Channel to be used for creating Fibre Channel mapping on the source server when you are performing partition migration.

 

You can use the HMC command line interface to specify the port name. List all the valid port names of the Fibre Channel by running the lsnports command. From the list of the valid port names, specify the port name that you want to use by running the migrlpar command with the attribute

vios_fc_port_name specifying the port name you want to use.

 

The following attributes of pseudo device can be modified by using the migrlpar command:

 

• num_active_migrations_configured
• concurr_migration_perf_level

 

Run the following HMC command to modify the attribute values of the pseudo device, for example to set the number of active migrations to 8 run:

 

$ migrlpar -o set -r lpar -m 795-1 -p lpar1 -i "num_active_migrations_configured=8“

 

The default value for this attribute is 4. To run the maximum number of supported partition mobility operations on the VIOS, this value must be set the supported maximum number.

 

To set the amount of resources allocated for each mobility operation to a value of 2, run the following command:

 

$ migrlpar -o set -r lpar -m 795-1 -p lpar1 -i "concurr_migration_perf_level=2"

 

The range of the concurr_migration_perf_level attribute value is 1 to 5. A value of 1 indicates optimal performance, and a value of 5 indicates limited resources. The default value is 3.

 

http://pic.dhe.ibm.com/infocenter/powersys/v3r1m5/index.jsp?topic=%2Fp7hc3%2Fiphc3hmclpmpseudo.htm

 

New LPM error codes.

 

There are new error codes available for troubleshooting partition mobility:

 

http://pic.dhe.ibm.com/infocenter/powersys/v3r1m5/index.jsp?topic=%2Fp7hc3%2Fiphc3hmctroubleshoot.htm

 

http://pic.dhe.ibm.com/infocenter/powersys/v3r1m5/index.jsp?topic=%2Fp7hc3%2Fiphc3vioserror.htm

 

VIOS error codes
Error Code	Definition
1	The virtual adapter is not ready to be moved. The source virtual Ethernet is not bridged.
2	The virtual adapter can be moved with less capability. All virtual local area networks (VLAN) are not bridged on the destination. Hence, the virtual Ethernet adapter has less capability on the target system compared to the source system.
3	The stream ID is still in use.
64	The migmgr command cannot be started.
65	The stream ID is invalid.
66	The virtual adapter type is invalid.
67	The virtual adapter DLPAR resource connector (DRC) name is not recognized.
68	The virtual adapter method cannot be started, or it was prematurely terminated.
69	There is a lack of resources (that is, the ENOMEM error code).
80	The storage that is being used by the adapter is specific to the VIOS and cannot be accessed by another VIOS. Hence, the virtual adapter cannot complete the mobility operation.
81	The virtual adapter is not configured.
82	The virtual adapter cannot be placed in a migration state.
83	The virtual devices are not found.
84	The virtual adapter VIOS level is insufficient.
85	The virtual adapter cannot be configured.
86	The virtual adapter is busy and cannot be unconfigured.
87	The virtual adapter or device minimum patch level is insufficient.
88	The device description is invalid.
89	The command argument is invalid.
90	The virtual target device cannot be created because of incompatible backing device attributes. Typically, this is because of a mismatch in the maximum transfer (MTU) size or SCSI reserve attributes of the backing device between the source VIOS and the target VIOS.
91	The DRC name passed to the migration code is for an adapter that exists.