TSM – Installation Manager fails to complete prereq check
Problem
The on screen message reports:
Exception caught while evaluating expression in bundle "com.tivoli.dsm.prereq.oscheck".
Symptom
Within the Installation Manager logs, the following messages are logged in the
00:20.22 ERROR: com.tivoli.dsm.prereq.utils.OSUtils.<init>(82) : An Exception was thrown while trying to get operating system information
00:20.22 ERROR: com.tivoli.dsm.prereq.utils.OSUtils.<init>(83) : CTGRI0039E An error occurred while attempting to execute a Visual Basic script. The following error information was returned: | CScript Error: Failed to load the configuration. (Access denied. )
Cause
Incorrect user being used during installation/upgrade.
Resolving the problem
Review the following requirements for the user ID performing the installation/upgrade here:
Windows: Installing Tivoli Storage Manager by using the installation wizard
Ensure that the user ID that you plan to use during the installation is a user with local Administrator authority.
Installing the V7.1.1 server and verifying the upgrade
You must be logged on to the system with the administrative user ID that was used to install the V6.2 or V6.3 server.
SLOW STARTUP PERFORMANCE OF THE 7.1 SERVER ON WINDOWS
Abstract
The default value for the DB2 database parameter DB_MEM_THRESH changed in DB2 version 10.5 and can lead to slow startup performance of the 7.1 server on Windows.
Content
ERROR DESCRIPTION:
It is possible to see the server startup take significantly longer to start up than is expected. The delay is experienced when the DB2 DB_MEM_THRESH value is set to 100 and there are large bufferpools.
The delay affects either, newly installed Tivoli Storage Manager Version 7.1.x, or upgrades from Tivoli Storage Manager V5.x to 7.1.x on Windows systems.
Upgrades from V6.x to 7.1.0.00 or higher do not show this behavior, since the DB_MEM_THRESH value is not changed to 100. The delay does not affect normal server operations, only server startup.
Tivoli Storage Manager Versions Affected: 7.1
Customer/L2 Diagnostics: The following commands can be run on a
DB2 command line to verify the setting for DB_MEM_THRESH.
db2 connect to TSMDB1
db2 get db cfg for TSMDB1 | find "DB_MEM_THRESH"
Output should be similar to the following.
C:\Program Files\Tivoli\TSM\db2\BIN>db2 get db cfg for TSMDB1 |
find
"DB_MEM_THRESH"
Database memory threshold (DB_MEM_THRESH) = 100
If you see DB_MEM_THRESH set to 100 and are running server version 7.1 on Windows then this APAR applies.
Initial Impact: Medium
Additional Keywords: startup start mem perf slow start up
performance
LOCAL FIX:
The following steps can be done while the TSM server is running and does not require that the TSM server be restarted.
The DB_MEM_THRESH value can be changed to the previous default
of 10 by issuing the following DB2 commands.
db2 connect to TSMDB1
db2 update db cfg for TSMDB1 using DB_MEM_THRESH 10
The output should look similar to the following.
C:\Program Files\Tivoli\TSM\db2\BIN>db2 update db cfg for TSMDB1
using
DB_MEM_THRESH 10
DB20000I The UPDATE DATABASE CONFIGURATION command completed
successfully.
Minimum NIM master levels for VIOS clients
The NIM master level for VIOS is also for me a good point of vue to know the AIX level vs VIOS ioslevel.
https://www-304.ibm.com/webapp/set2/sas/f/flrt/viostable.html
Minimum NIM master levels for VIOS clients
If using NIM to backup, install or update a VIOS partition, the NIM master must be greater than or equal to the levels shown below.
VIOS Release | VIOS Level | Minimum NIM master level | ||||
---|---|---|---|---|---|---|
VIOS 2.2.6 | VIOS 2.2.6.10 | AIX 6100-09-10 | 7100-05-01 | 7200-02-01 | ||
VIOS 2.2.6.0 | AIX 6100-09-10 | 7100-05-00 | 7100-02-00 | |||
VIOS 2.2.5 | VIOS 2.2.5.30 | AIX 6100-09-10 | 7100-05-01 | 7200-02-01 | ||
VIOS 2.2.5.20 | AIX 6100-09-09 | 7100-04-04 | 7200-01-02 | |||
VIOS 2.2.5.10 | AIX 6100-09-08 | 7100-04-03 | 7200-01-01 | |||
VIOS 2.2.5.0 | AIX 6100-09-08 | 7100-04-03 | ||||
VIOS 2.2.4 | VIOS 2.2.4.50 | AIX 6100-09-10 | 7100-05-01 | 7200-02-01 | ||
VIOS 2.2.4.40 | AIX 6100-09-09 | 7100-04-04 | 7200-01-02 | |||
VIOS 2.2.4.30 | AIX 6100-09-08 | 7100-04-03 | 7200-01-01 | |||
VIOS 2.2.4.23 | AIX 6100-09-07 | 7100-04-02 | 7200-00-02 | |||
VIOS 2.2.4.22 | AIX 6100-09-07 | 7100-04-02 | 7200-00-02 | |||
VIOS 2.2.4.21 | AIX 6100-09-07 | 7100-04-02 | 7200-00-02 | |||
VIOS 2.2.4.20 | AIX 6100-09-07 | 7100-04-02 | 7200-00-02 | |||
VIOS 2.2.4.10 | AIX 6100-09-06 | 7100-04-01 | 7200-00-01 | |||
VIOS 2.2.4.0 | AIX 6100-09-06 | 7100-04-01 | 7200-00-01 | |||
VIOS 2.2.3 | VIOS 2.2.3.90 | AIX 6100-09-09 | 7100-04-04 | 7200-01-02 | ||
VIOS 2.2.3.80 | AIX 6100-09-08 | 7100-04-03 | 7200-01-01 | |||
VIOS 2.2.3.70 | AIX 6100-09-07 | 7100-04-02 | 7200-00-02 | |||
VIOS 2.2.3.60 | AIX 6100-09-06 | 7100-03-05 | ||||
VIOS 2.2.3.50 | AIX 6100-09-05 | 7100-03-05 | ||||
VIOS 2.2.3.4 | AIX 6100-09-04 | 7100-03-04 | ||||
VIOS 2.2.3.3 | AIX 6100-09-03 | 7100-03-03 | ||||
VIOS 2.2.3.2 | AIX 6100-09-02 | 7100-03-02 | ||||
VIOS 2.2.3.1 | AIX 6100-09-01 | 7100-03-01 | ||||
VIOS 2.2.3.0 | AIX 6100-09 | 7100-03 | ||||
VIOS 2.2.2 | VIOS 2.2.2.70 | AIX 6100-08-07 | 7100-02-07 | |||
VIOS 2.2.2.6 | AIX 6100-08-06 | 7100-02-06 | ||||
VIOS 2.2.2.5 | AIX 6100-08-05 | 7100-02-05 | ||||
VIOS 2.2.2.4 | AIX 6100-08-04 | 7100-02-04 | ||||
VIOS 2.2.2.3 | AIX 6100-08-03 | 7100-02-03 | ||||
VIOS 2.2.2.2 | AIX 6100-08-02 | 7100-02-02 | ||||
VIOS 2.2.2.1 | AIX 6100-08-01 | 7100-02-01 | ||||
VIOS 2.2.2.0 | AIX 6100-08 | 7100-02 | ||||
VIOS 2.2.1 | VIOS 2.2.1.9 | AIX 6100-07-10 | 7100-01-10 | |||
VIOS 2.2.1.8 | AIX 6100-07-09 | 7100-01-09 | ||||
VIOS 2.2.1.7 | AIX 6100-07-08 | 7100-01-07 | ||||
VIOS 2.2.1.5 | AIX 6100-07-05 | 7100-01-05 | ||||
VIOS 2.2.1.4 | AIX 6100-07-04 | 7100-01-04 | ||||
VIOS 2.2.1.3 | AIX 6100-07-02 | 7100-01-02 | ||||
VIOS 2.2.1.1 | AIX 6100-07-01 | 7100-01-01 | ||||
VIOS 2.2.1.0 | AIX 6100-07 | 7100-01 | ||||
VIOS 2.2.0 | VIOS 2.2.0.13 | AIX 6100-06-05 | 7100-00-03 | |||
VIOS 2.2.0.12 | AIX 6100-06-05 | 7100-00-03 | ||||
VIOS 2.2.0.11 | AIX 6100-06-03 | 7100-00-02 | ||||
VIOS 2.2.0.10 | AIX 6100-06-01 | 7100-00-01 | ||||
VIOS 2.2.0.0 | AIX 6100-06 | 7100-00 | ||||
VIOS 2.1.3 | VIOS 2.1.3.10 | AIX 6100-05-02 | ||||
VIOS 2.1.3.0 | AIX 6100-05 | |||||
VIOS 2.1.2 | VIOS 2.1.2.13 | AIX 6100-04-03 | ||||
VIOS 2.1.2.12 | AIX 6100-04-02 | |||||
VIOS 2.1.2.11 | AIX 6100-04-02 | |||||
VIOS 2.1.2.10 | AIX 6100-04-01 | |||||
VIOS 2.1.2.0 | AIX 6100-04 | |||||
VIOS 2.1.1 | VIOS 2.1.1.10 | AIX 6100-03-01 | ||||
VIOS 2.1.1.0 | AIX 6100-03 | |||||
VIOS 2.1.0 | VIOS 2.1.0.10 | AIX 6100-02-02 | ||||
VIOS 2.1.0.1 | AIX 6100-02-01 | |||||
VIOS 2.1.0.0 | AIX 6100-02 | |||||
VIOS 1.5.2 | VIOS 1.5.2.6 | AIX 5300-08-08 | ||||
VIOS 1.5.2.5 | AIX 5300-08-05 | |||||
VIOS 1.5.2.1 | AIX 5300-08-01 | |||||
VIOS 1.5.2.0 | AIX 5300-08 |
BACKUP VM uses NBD over SAN transport
Technote (troubleshooting)
Problem(Abstract)
Although "VMVSTORTRANSPORT SAN" is set in the datamovers options file, the backup uses NBD.
Symptom
Backup uses NBD transport
Cause
VMware vCenter 'SSL.VERSION' setting is set to TLSv1.
This option can be found in the VMware vSphere client -> Administration -> vCenter Server Settings -> Advanced Settings.
Environment
Windows/Linux datamover.
vCenter 5.1 or 5.5.
Diagnosing the problem
A Tivoli Storage Manager client trace will show the following:
Cannot use advanced transport modes for VCENTER/moRef=vm-12345/snapshot-6789: Other error encountered: SSL Exception: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure.
Resolving the problem
The SSL.VERSION parameter needs to either be set to 'ALL', or if TLS is a requirement, then the Tivoli Storage Manager client (datamover) must be upgraded to version 7.1.2.x. This version of client includes VDDK version 6.0 which has added support for TLS.
https://www.vmware.com/support/developer/vddk/vddk-600-releasenotes.html#whatsnew
PowerHA Service Pack APAR content Matrix
Source : IBM Technote
Last Updated: 7/24/2015
Table View: (Links to list/description of APARs in each service pack)
PowerHA SystemMirror Version
|
||||
V6.1
|
V7.1.0
|
V7.1.1
|
V7.1.2
|
V7.1.3
|
SP1 – 12/1/2009 | SP1 – 9/1/2010 | SP1 – 2/1/2012 | SP1 – 11/1/2012 | SP1 - 5/16/2014 |
SP2 – 5/1/2010 | SP2 – 11/1/2010 | SP2 – 3/1/2012 | SP2 – 3/1/2013 | SP2 - 11/10/2014 |
SP3 – 9/1/2010 | SP3 – 12/1/2010 | SP3 – 7/1/2012 | SP3 – 7/1/2013 | SP3 - 3/27/2015 |
SP4 – 1/1/2011 | SP4 – 8/1/2011 | SP4 – 12/1/2012 | SP4 - 6/23/2014 | |
SP5 – 4/1/2011 | SP5 – 3/1/2012 | SP5 – 5/1/2013 | SP5 - 11/21/2014 | |
SP6 – 8/1/2011 | SP6 – 10/1/2012 | SP6 – 2/19/2014 | SP6 - 7/24/2015 | |
SP7 – 12/1/2011 | SP7 – 2/1/2013 | SP7 - 8/26/2014 | ||
SP8 – 5/1/2012 | SP8 – 6/1/2013 | SP8 - 3/3/2015 | ||
SP9 – 8/1/2012 | SP9 – 5/9/2014 | SP9 - 5/27/2015 | ||
SP10 – 1/1/2013 | ||||
SP11 – 5/1/2013 | ||||
SP12 – 9/1/2013 | ||||
SP13 - 7/30/2014 | ||||
SP14 - 11/21/2014 | ||||
SP15 - 4/27/2015 |
Determining rlimit (ulimit) values for a running process
Question
How can I find out what limits are set for a currently running process?
Answer
The easiest way is to download the pdump.sh script and run it against the process. The pdump tool can be downloaded from here:
ftp://ftp.software.ibm.com/aix/tools/debug/
There is no installation needed, only to change the permissions of the file so it can be executed:
$ chmod +x pdump.sh
Then run it against the process-id (PID) of the process you wish to examine. The pdump.sh script will create an output file containing information regarding that process.
# ./pdump.sh 3408030
The output file will contain the name of the process, the PID and the current date. For example:
pdump.tier1slp.3408030.13May2015-11.18.13.out
This is an ASCII text file and can be inspected with "more" or "view".
Determining the limit values
Limits in a process are kept in the user area or "uarea" of the process memory. This section in the pdump output starts with the title "Resource limits:"
Resource limits:
fsblimit....00000000001FFFFF
rlimit[CPU]........... cur 7FFFFFFF max 7FFFFFFF
saved_rlimit[CPU]..... cur 7FFFFFFFFFFFFFFF max 7FFFFFFFFFFFFFFF
rlimit_flag[CPU]...... cur INF max INF
rlimit[FSIZE]......... cur 3FFFFE00 max 3FFFFE00
saved_rlimit[FSIZE]... cur 000000003FFFFE00 max 000000003FFFFE00
rlimit_flag[FSIZE].... cur SML max SML
rlimit[DATA].......... cur 08000000 max 7FFFFFFF
saved_rlimit[DATA].... cur 0000000008000000 max 7FFFFFFFFFFFFFFF
rlimit_flag[DATA]..... cur SML max INF
rlimit[STACK]......... cur 02000000 max 7FFFFFFF
saved_rlimit[STACK]... cur 0000000002000000 max 0000000100000000
rlimit_flag[STACK].... cur SML max MAX
rlimit[CORE].......... cur 3FFFFE00 max 7FFFFFFF
saved_rlimit[CORE].... cur 000000003FFFFE00 max 7FFFFFFFFFFFFFFF
rlimit_flag[CORE]..... cur SML max INF
rlimit[RSS]........... cur 02000000 max 7FFFFFFF
saved_rlimit[RSS]..... cur 0000000002000000 max 7FFFFFFFFFFFFFFF
rlimit_flag[RSS]...... cur SML max INF
rlimit[AS]............ cur 7FFFFFFF max 7FFFFFFF
saved_rlimit[AS]...... cur 0000000000000000 max 0000000000000000
rlimit_flag[AS]....... cur INF max INF
rlimit[NOFILE]........ cur 000007D0 max 7FFFFFFF
saved_rlimit[NOFILE].. cur 00000000000007D0 max 7FFFFFFFFFFFFFFF
rlimit_flag[NOFILE]... cur SML max INF
rlimit[THREADS]....... cur 7FFFFFFF max 7FFFFFFF
saved_rlimit[THREADS]. cur 0000000000000000 max 0000000000000000
rlimit_flag[THREADS].. cur INF max INF
rlimit[NPROC]......... cur 7FFFFFFF max 7FFFFFFF
saved_rlimit[NPROC]... cur 0000000000000000 max 0000000000000000
rlimit_flag[NPROC].... cur INF max INF
The resource limit for each ulimit value is represented here. As values could be either 32-bit or 64-bit, the include file /usr/include/sys/user.h tells us how to read them:
/*
* To maximize compatibility with old kernel code, a 32-bit
* representation of each resource limit is maintained in U_rlimit.
* Should the limit require a 64-bit representation, the U_rlimit
* value is set to RLIM_INFINITY, with actual 64-bit limit being
* stored in U_saved_rlimit. These flags indicate what
* the real situation is:
*
* RLFLAG_SML => limit correctly represented in 32-bit U_rlimit
* RLFLAG_INF => limit is infinite
* RLFLAG_MAX => limit is in 64_bit U_saved_rlimit.rlim_max
* RLFLAG_CUR => limit is in 64_bit U_saved_rlimit.rlim_cur
So using this and our pdump output, we can view the value of NOFILE for example:
rlimit[NOFILE]........ cur 000007D0 max 7FFFFFFF
saved_rlimit[NOFILE].. cur 00000000000007D0 max 7FFFFFFFFFFFFFFF
rlimit_flag[NOFILE]... cur SML max INF
The rlimit_flag for NOFILE is set to SML, so the value is a 32-bit integer, and is stored in the rlimit.cur variable.
0x7d0 = 2000 decimal, so the limit for that user, picked up by the process when it started, is 2000.
Source : IBM Technote
VIOS Adapter_reset on SEA LOAD SHARING
Technote (FAQ)
Question
How can I prevent network outage on SEA in loadsharing mode over physical adapter/LACP(8023ad link aggregation).
Answer
SEA load sharing is initiated by Backup SEA. In the VIOS levels (older than 2.2.4.0), SEA going to Backup state calls for adapter reset by default.
Some physical adapters may takes 30 sec or longer to complete adapter reset and LACP negotiation may take 30 sec for LACP negotiation. If SEA is configured with those physical adapters or LACP, network communication for the SEA in backup_sh state may be affected temporarily during a system reboot or cable pull/plug back in.
Changing value of "adapter_reset" attribute to "no" on a pair of SEA in loadsharing mode.
1. Login to padmin
2. Change to root prompt:
$ oem_setup_env
3. List the adapters:
# lsdev -Cc adapter
4. Find the Shared Ethernet Adapters
ent7 Available Shared Ethernet Adapter
5. Use the entstat command to list the components of the SEA:
# entstat -d ent7 | grep State
On SEA in primary loadsharing mode
State : PRIMARY_SH
On SEA in backup loadsharing mode
State : BACKUP_SH
6. Use the lsattr command to list attributes of the SEA
# lsattr -El ent7
adapter_reset yes
7. Change adapter_reset to "no". This change is dynamic and doesn't require reboot.
chdev -dev ent7 -attr adapter_reset=no
8. Use the lsattr command to confirm the change
# lsattr -El ent7
adapter_reset no
Common EFS Errors and Solutions
Question
This document is a collection of errors encountered when using EFS and solutions to those issues.
Answer
1) Problem: Can't enable EFS on the system
# efsenable -a
/usr/lib/drivers/crypto/clickext: A file or directory in the path name does not exist.
Unable to load CLiC kernel extension. Please check your installation.
Solution:
Install CLiC filesets from AIX Expansion Pack CD
$ installp -l -d clic.rte
Fileset Name Level I/U Q Content
====================================================================
clic.rte.includes 4.3.0.0 I N usr
# CryptoLite for C Library Include File
clic.rte.kernext 4.3.0.0 I N usr,root
# CryptoLite for C Kernel
clic.rte.lib 4.3.0.0 I N usr
# CryptoLite for C Library
2) Problem: Can't enable EFS on the system
# efsenable -a
Unable to load CLiC kernel extension. Please check your installation.
(Please make sure latest version of clic.rte is installed.)
Double-check that you have installed the correct version of the CLIC filesets for your Technology Level of AIX.
For AIX 6100-01 use clic.rte.4.3.0.0.I on the Expansion Pack CD
For aix 6100-02 use clic.rte.4.5.0.0.I on the Expansion Pack CD
AIX 6100-03 has been updated to include clic.rte on the base media set to prevent boot issues on systems with EFS enabled. Use clic.rte.4.6.0.1.I
For AIX 6100-04 use clic.rte.4.7.0.0.I which is also included in the base OS media.
2) Problem: Can't view user's key:
$ efskeymgr -v
Problem initializing EFS framework.
Please check EFS is installed and enabled (see efsenable) on you system.
Error was: (EFS was not configured)
Solution:
Enable EFS on the system:
# efsenable -a
and give root's password when it asks for root's initial keystore.
3) Problem: Can't enable encryption inheritiance on a directory.
# efsmgr -E testdir
or
Can't enable encryption on a specific file
# efsmgr -e myfile
Problem initializing EFS framework.
Please check EFS is installed and enabled on you system.
Error was: (EFS was not configured)
Solution:
Make sure CLiC filesets are installed
Enable EFS on the system
Enable EFS and RBAC on the filesystem:
# chfs -a efs=yes /myfilesystem
4) Problem: Have enabled EFS on a filesystem but get error mounting:
# mount /efstest
The CLiC library (libclic.a) is not available. Install clic.rte and run 'efsenable -a'.
Solution:
Install CLiC filesets
Enable EFS on the system
Remount the filesystem
5) Problem: No encryption algorithms show up!
# efsenable -q
List of supported algorithms for keystores:
1
2
3
List of supported ciphers for files:
1
2
3
4
5
6
Solution:
Install CLiC filesets
# efsenable -q
List of supported algorithms for keystores:
1 RSA_1024
2 RSA_2048
3 RSA_4096
List of supported ciphers for files:
1 AES_128_CBC
2 AES_192_CBC
3 AES_256_CBC
4 AES_128_ECB
5 AES_192_ECB
6 AES_256_ECB
Source: IBM Technote
How to check for memory over-commitment in AME
Question
In LPARs that utilize the Power 7 (and later) feature of Active Memory Expansion (AME), assessing memory resources is a more complex task compared with dedicated memory systems. How can the memory in such a system be evaluated?
Answer
Introduction
Active Memory Expansion (AME) allows for the compression of memory pages to increase the system's effective virtual address space. At high usage, unused computational memory is moved to the compressed pool instead of being paged-out to paging space. This is typically employed in environments with excess CPU resources and are somewhat constrained on physical memory. Active Memory Expansion is feature that has been introduced in POWER7/POWER7+ systems with a minimum level of AIX 6.1 TL4 SP2.
AME Scenarios
After planning and configuring the system with the amepat tool, there are some scenarios that might require a change of AME configuration:
- Virtual memory exceeds Target Memory Expansion Size
- Virtual memory exceeds assigned physical memory and less than Target Memory Expansion Size (with no deficit)
- Virtual memory exceeds assigned physical memory and less than Target Memory Expansion Size (with deficit)
- Virtual memory is below assigned physical memory
When this scenario is present, the system is over-committed and will start paging out to disk. From a configuration stand-point, rerun the amepat tool to either increase the Expansion Factor or to increase the size of physical memory.
This is the ideal scenario when using AME as the compressed pool is able to satisfy the memory demands of the LPAR.
When the system is unable to compress memory pages to meet the Target Memory Expansion Size, there will be a deficit and pages that exceed the allocated memory are moved to paging space. Not all memory pages are subject to compression (pinned pages or client pages) and therefore, a deficit is present. Rerun the amepat tool to either decrease the Expansion Factor or to increase the size of physical memory.
While there isn't a problem with over-commitment with this setup, it is not benefiting from AME. Rerun the amepat tool to decrease the allocated physical memory and evaluate the current Expansion Factor.
Tools to use with a live example
The following tools on AIX can be used to determine the current status of an AME-enabled LPAR (with a live example from the IBM Redbook IBM PowerVM Virtualization Managing and Monitoring):
# amepat
- Comparing the Virtual Memory Size (MB) to the Target Expanded Memory Size, we find that the system is not over-committed logically.
- Due to the Deficit Memory Size (MB), the system will start utilizing paging space due to the inability to compress more memory.
# vmstat -c
Comparing the avm value (in 4k pages) to the tmem value (MB) will tell us if the system is logically over-committed.
- Observing the dxm will show us the deficit in 4k pages.
# svmon -O summary=AME
Comparing the virtual column to the size column shows no issue with logical memory over-commitment.
- The dxm column shows the deficit in 4k pages
For more information regarding AME, please refer to the IBM Redbook IBM PowerVM Virtualization Managing and Monitoring (sg247590):
http://www.redbooks.ibm.com/abstracts/sg247590.html
Source: IBM Technote
IBM AIX – From Strength to Strength – 2014
Un document intéressant qui résume les fonctionnalités et supports par version d'AIX, Vitual I/O Server et autres produits pour IBM POWER.
Lien permanent :
http://public.dhe.ibm.com/common/ssi/ecm/en/poo03022usen/POO03022USEN.PDF
Thank you Jay.