What is AIX 6100-00-05Service Packs contain important fixes delivered between Technology Levels. 6100-00-05 is Service Pack 5 for the 6100-00 Technology Level.

How to Obtain AIX 6100-00-05AIX 6100-00 Service Pack 5 may be obtained from the Fix packs section of the Fix Central web site, or by ordering APAR IZ24009.

Installation TipsYou must have root authority to perform the installation.

Creating a system backup is recommended before starting the installation procedure. Refer to the mksysb command in the AIX 6.1 Commands Reference manual for additional information.

The latest AIX 6.1 installation hints and tips are available from the IBM Subscription Service.
These tips contain important information that should be reviewed prior to installation.

InstallationTo install all updates from this package that apply to installed filesets on your system, use the command:
smit update_all
A system reboot is required after the installation completes successfully.
To determine if the 6100-00 Service Pack 5 is installed, use the command:

oslevel -s
The output should indicate 6100-00-05-0822.

Just a quick note since I hear of people running into this issue all the time.

I’m unsure if this is an HBA firmware issue, or if it ‘works as expected’, but when plugging a Fiber cable into an HBA while it’s attached to an LPAR, you will not get a link immediately. Actually, this isn’t even LPAR specific, I have had this happen with physical systems as well.
From past experiences, you’ll have to rmdev -dl the fcs0,fcnet0,fscsi0,etc and run cfgmgr to bring the device back in. This seems to perform some sort of virtual power off/on type of situation, then will reconfigure the device and it will have a link. I’m not sure if this is just the environment I’m working with or not, but it happens every time a cable is plugged in while the system is live!

mksysb’s can come in handy for various situations. Whether you’re doing an upgrade, or just wanting a backup of a system, I definitely recommend using the mksysb command.
Creating a mksysb is a very simple process. First you need to make sure you have enough space free to dump it to, then just kick it off.

I generally run something like:

"mksysb -iep /mksysb_dump.mksysb

I generally create an NFS share from the NIM server, and mount it up on each AIX client in order to dump a weekly mksysb. The overall process actually ssh’s to the remote AIX client, mounts the NFS share, dumps a mksysb, compresses, umount, done.

With having issues in the past using the software compression within the mksysb process, I generally use the -p flag to disable software compression, and gzip at a later time. With a very busy rootvg, you will probably most likely have to disable compression, as you will likely run into issues restoring it.
Have fun.

Just a very brief how to on the patching.
You can download the TL8 patch set from the following URL: http://www-933.ibm.com/eserver/support/fixes/fixcentral/pfixpacks/53

First you’ll generally want to commit all existing filesets in cases there are any issues with TL8, so you can back out more easily.
The following will commit all previously applied filesets:
/usr/lib/instl/sm_inst installp_cmd -c -f'all' '-g' '-X' '-V2'

Transfer the patch cluster to your server and decompress. Once that’s complete, run the following to preview the process:

/usr/sbin/install_all_updates -d -p -V -Y

Verify that everything looks good, then continue with:
/usr/sbin/install_all_updates -d -V -Y
Sit back and wait… Once complete, it would generally be a good idea to run through errpt, as well as a reboot then check it out again. Watch the console on boot for any odd boot messages or errors starting any services.

Verify the patching by checking the oslevel:
oslevel -s

While doing some 5.0MP1 upgrades recently, I noticed that MPIO no longer controlled my vscsi root disks, coming from a Virtual I/O server. This was definitely not what I wanted. After a few calls and a few hours on the phone, I was finally told that MP1 finally had support for vscsi devices within Veritas, hence DMP taking control for multi-pathing. Due to the way I use vscsi devices for root disks, we had to disable this support. vscsi disks will still work through Veritas, they just use the standard ‘aixdisk’ format, rather than vscsi. To disable vscsi support I had to run the following
‘/usr/lib/vxvm/bin/vxdmpvscsi disable’, then reboot

Once the LPAR boot back up, everything was good to go. Existing volumes using vscsi devices continued to function.

The good: You can disable it
The bad: There’s no way to disable it before applying MP1… ugh.

http://www14.software.ibm.com/webapp/set2/subscriptions/pqvcmjd?mode=18&ID=4219

Readme file updated for PTF U814685 for HMC Version 3 Release 3.3.7)
Description:

The readme file for PTF U814685 stated to install PTF U809968. However, since PTF U810401 supersedes PTF U809968, the readme file has been updated.

After installing PTF U814685, PTFs U808917 and U810401 must be installed.

In addition, the PTF U810401 readme file has been updated to state that it supersedes PTF U809968.

Note: PTF U809968 has been removed from the web.

View the U814685 Readme file for fix and enhancement information.

View the U810401 Readme file for fix and enhancement information.

Visit Hardware Management Console for all the latest updates.

http://www14.software.ibm.com/webapp/set2/subscriptions/pqvcmjd?mode=18&ID=4197

Readme file updated for PTF U814685 for HMC Version 3 Release 3.3.7)
Description:

A problem has been identified where the readme file for PTF U814685 incorrectly listed PTFs U810401, U809968 and U808917 as being included. When in fact, they were not.

PTFs U810401, U809968 and U808917 must be installed AFTER installing PTF U814685.

View the U814685 Readme file for fix and enhancement information.

Visit Hardware Management Console for all the latest updates

Service Packs contain important fixes delivered between Technology Levels. 6100-00-04 is Service Pack 4 for the 6100-00 Technology Level.

http://www.ibm.com/support/docview.wss?uid=isg1IZ17881

High Impact/Highly Pervasive APAR

APAR Number: IZ17881

——————————————————————————–

APAR status
Closed as program error.

Error description
Sockets may not get freed if an application is using the
pollset APIs to poll on the sockets. This may cause the
memory leak (i.e. memory usage slowly increasing) until
the system becomes very sluggish or even hangs. The problem
has been seen when running a DB2 v9.1 client.
Local fix
Problem summary
****************************************************************
* USERS AFFECTED:
* Users of AIX 6.1 with the bos.mp64 fileset below the leve of
* 6.1.0.5.
****************************************************************
* PROBLEM DESCRIPTION:
* Sockets may not get freed if an application is using the
* pollset APIs to poll on the sockets. This may cause the
* memory leak (i.e. memory usage slowly increasing) until
* the system becomes very sluggish or even hangs. The problem
* has been seen when running a DB2 v9.1 client.
****************************************************************
* RECOMMENDAION:
* Install APAR IZ17881.
****************************************************************
Problem conclusion
AIX kernel was fixed to correctly manage the socket
reference count along the pollset API paths such that the
sockets can be freed after they are closed. Freeing the
sockets ensures that the memory is returned to AIX and is
not leaked.
Temporary fix
*********
* HIPER *
*********

Comments
APAR information
APAR number IZ17881
Reported component name AIX 610
Reported component ID 5765G6200
Reported release 610
Status CLOSED PER
PE NoPE
HIPER YesHIPER
Submitted date 2008-03-15
Closed date 2008-03-15
Last modified date 2008-04-07

APAR is sysrouted FROM one or more of the following:
IZ17873

APAR is sysrouted TO one or more of the following:

Fix information
Fixed component name AIX 610
Fixed component ID 5765G6200

Applicable component levels
R610 PSY U816201 UP08/04/07 I 1000

http://www.ibm.com/support/docview.wss?uid=isg1IZ17558

On very loaded systems, this may not give the gsclvmd
process enough time to respond to the check, resulting in
the VG being forced offline during times of heavy system
load.
Customers could see, in the errpt, LVM_GS_LLEAVE
followed by LVM_SA_QUORCLOSE on the node where the VG was
forced offline, and see LVM_GS_RLEAVE on other nodes
in the cluster.
.
.
A related issue is: when an LVM configuration or stale
partition update happens in a concurrent VG, gsclvmd must
get approval from every node before making the change.
In doing so, currently gsclmvd will wait forever until
all remote nodes respond in some fashion.
.
Under certain problematic conditions, this behavior is
undesirable and can cause the LVM commands to wait
indefinitely.
Local fix
Problem summary
****************************************************************
* USERS AFFECTED:
* Customers may be exposed to this problem if the have the
* bos.clvm.enh fileset at a level below 6.1.0.2.
* They must also be using Concurrent LVM, which is utilized by
* HACMP Resource Groups using Fast Disk Takeover or the ‘Online
* on All Available Notes’ Startup Policy.
****************************************************************

* PROBLEM DESCRIPTION:
* On extremely busy clusters, or clusters experiencing poor
* network communication, the concurrent LVM daemon (gsclvmd) on
* a node may fail to respond to a responsiveness check issued by
* Group Services. In this case, we will force the Volume Group
* offline on that node to ensure there is no possibility that
* future LVM configuration changes will cause the Volume Group
* definition to become out of sync between the two nodes.
* However, forcing the VG offline could lead to unexpected
* downtime of applications using that volume group, or potential
* problems during HACMP failover.
****************************************************************
* RECOMMENDATION:
* Install APAR IZ17558.
****************************************************************
Problem conclusion
Both of the behaviors of gsclvmd described above will be
changed.
.
By default, we will no longer expel a node and force it’s
VG offline if it fails a responsiveness check.
A flag will be added to varyonvg that will allow you to
enable this behavior (expeling non responsive nodes) if
desired.
.
Also, if a node takes longer than 5 minutes to reply to
a vote (taken before making an LVM configuration change
or stale partition update on a concurrent VG), then we
will expel that node and the VG on that node will be
forced offline. You will see LVM_GS_CFGTIME followed
by LVM_GS_LLEAVE or LVM_GS_RLEAVE in the errpt if this
happens.
.
.
*Note: due to the changes in the default behavior of
gsclvmd, this apar needs to be applied to all nodes in
the cluster. If not, there may be problems if ever
a node is un-responsive to either a responsiveness
check or a vote request.
Temporary fix
*********
* HIPER *
*********
Comments
APAR information
APAR number IZ17558
Reported component name AIX 610
Reported component ID 5765G6200
Reported release 610
Status CLOSED PER
PE NoPE
HIPER YesHIPER
Submitted date 2008-03-11
Closed date 2008-03-11
Last modified date 2008-04-07

APAR is sysrouted FROM one or more of the following:
IZ13557

APAR is sysrouted TO one or more of the following:
U817458

Fix information
Fixed component name AIX 610
Fixed component ID 5765G6200

Applicable component levels
R610 PSY U817458 UP08/04/07 I 1000