Chris's AIX Blog

It’s no secret that I like NIM. I’ve written about NIM on several occasions, in Redbooks, technical articles and on my blog. It’s a great tool for installing and maintaining AIX. Occasionally though, it can throw you an unusual error or two when things go wrong. For the uninitiated resolving these errors can be challenging.

 

Here’s a couple of NIM related questions I received recently. Both are troubleshooting queries.

 

“I'm getting the following error when trying to create a NIM lpp_source for AIX 6.1”:

 

                               Define a Resource

 

Type or select values in entry fields.

Press Enter AFTER making all desired changes.

 

                                                        [Entry Fields]

* Resource Name                               [6100-06_lpp]

* Resource Type                                lpp_source

* Server of Resource                          [master]                +

* Location of Resource                        [/export/eznim]          /

  NFS Client Security Method                  []                      +

  NFS Version Access                          []                      +

  Architecture of Resource                    []                      +

  Source of Install Images                    [/dev/cd0]              +/

  Names of Option Packages                    []

  Show Progress                               [yes]                   +

  Comments                                    []

 

...

Preparing to copy install images (this will take several minutes)...

 

0042-001 nim: processing error encountered on "master":

   0042-081 m_mk_lpp_source: a resource already exists on "master" at

location "/export/eznim/bid_ow"; due to NFS export restrictions, the

        new location "/export/eznim" may not be used

...

 

I could see what could be causing the issue but I first asked to see the contents of the /etc/exports file. Just to make sure that /export/eznim was not explicitly exported. It wasn’t.

 

# grep eznim /etc/exports

/export/eznim/vios/mksysb_image -ro,root=vio1,access=vio1

/export/eznim/bid_ow -ro,root=nim1,access=nim1

 

I suggested they re-try the operation again but this time specify the full path to the lpp_source directory, like so:

 

                               Define a Resource

 

Type or select values in entry fields.

Press Enter AFTER making all desired changes.

 

                                                        [Entry Fields]

* Resource Name                               [6100-06_lpp]

* Resource Type                                lpp_source

* Server of Resource                          [master]                +

* Location of Resource                        [/export/eznim/6100-06_lpp]          /

  NFS Client Security Method                  []                      +

  NFS Version Access                          []                      +

  Architecture of Resource                    []                      +

  Source of Install Images                    [/dev/cd0]              +/

  Names of Option Packages                    []

  Show Progress                               [yes]                   +

  Comments                                    []

 

This worked fine. And the lpp_source was created successfully.

 

#  lsnim -l 6100-06_lpp

6100-06_lpp:

   class       = resources

   type        = lpp_source

   locked      = 26738726

   Rstate      = unavailable for use

   prev_state  =

   location    = /export/eznim/6100-06_lpp

   alloc_count = 0

   server      = master

 

The second issue related to down-level filesets after an AIX 6.1 migration with nimadm.  There was also an issue with disk space that generated an error during NIM operations.

 

“Hi Chris,

 

Thanks for replying back to my post. I am a newbie to AIX/pSeries world.

I was following your document on upgrading AIX 5.3 to 6.1 using nimadm, it seemed to have worked partially for me, as I got to AIX 6100-00-00. The mksysb and the SPOT I created were for AIX 6100-06-05.

 

Before I re-attempt the upgrade, is there anything I need to be clean up on AIX 5.3 side that could have perhaps caused issues with the upgrade.

 

Thanks”

 

I recommended that the following command be run on the NIM client, to determine which filesets were down-level after the migration.

 

# oslevel -s

# instfix -i | grep AIX

# instfix -i | grep SP

 

If the output contained messages like "Not all filesets for 6100-06_AIX_ML were found", or something similar, then they should run the following command against each line (there could be more than one).

 

# instfix -icqk 6100-06_AIX_ML | grep ":-:"

 

This will tell you which filesets were not updated.

 

The output from ‘oslevel –s’and ‘instfix –i | grep AIX’ looked OK.

 

# oslevel -s

6100-06-04-1112

 

# instfix -i | grep AIX

    All filesets for 6100-00_AIX_ML were found.

    All filesets for 6100-01_AIX_ML were found.

    All filesets for 6100-02_AIX_ML were found.

    All filesets for 6100-03_AIX_ML were found.

    All filesets for 6100-04_AIX_ML were found.

    All filesets for 6100-05_AIX_ML were found.

    All filesets for 6100-06_AIX_ML were found.

 

But the output from ‘instfix –i  | grep SP’ indicated an issue with 61-06-051115_SP.

 

# instfix -i | grep SP

    All filesets for 61-00-010748_SP were found.

    All filesets for 61-00-020750_SP were found.

    All filesets for 61-00-030808_SP were found.

    All filesets for 61-00-040815_SP were found.

    All filesets for 61-01-010823_SP were found.

    All filesets for 61-00-050822_SP were found.

    All filesets for 61-00-060834_SP were found.

    All filesets for 61-01-020834_SP were found.

    All filesets for 61-00-070846_SP were found.

    All filesets for 61-01-030846_SP were found.

    All filesets for 61-02-010847_SP were found.

    All filesets for 61-02-020849_SP were found.

    All filesets for 61-00-080909_SP were found.

    All filesets for 61-01-040909_SP were found.

    All filesets for 61-02-030909_SP were found.

    All filesets for 61-03-010921_SP were found.

    All filesets for 61-00-090920_SP were found.

    All filesets for 61-01-050920_SP were found.

    All filesets for 61-02-040920_SP were found.

    All filesets for 61-00-100939_SP were found.

    All filesets for 61-01-060939_SP were found.

    All filesets for 61-02-050939_SP were found.

    All filesets for 61-03-020939_SP were found.

    All filesets for 61-04-010944_SP were found.

    All filesets for 61-04-021007_SP were found.

    All filesets for 61-04-031009_SP were found.

    All filesets for 61-00-110943_SP were found.

    All filesets for 61-01-081014_SP were found.

    All filesets for 61-02-060943_SP were found.

    All filesets for 61-03-030943_SP were found.

    All filesets for 61-03-041014_SP were found.

    All filesets for 61-04-041014_SP were found.

    All filesets for 61-05-011016_SP were found.

    All filesets for 61-01-091015_SP were found.

    All filesets for 61-02-081015_SP were found.

    All filesets for 61-03-051015_SP were found.

    All filesets for 61-04-051015_SP were found.

    All filesets for 61-01-070943_SP were found.

    All filesets for 61-02-071014_SP were found.

    All filesets for 61-02-091034_SP were found.

    All filesets for 61-03-061034_SP were found.

    All filesets for 61-04-061034_SP were found.

    All filesets for 61-05-021034_SP were found.

    All filesets for 61-06-011043_SP were found.

    All filesets for 61-02-101036_SP were found.

    All filesets for 61-03-071036_SP were found.

    All filesets for 61-04-071036_SP were found.

    All filesets for 61-05-031036_SP were found.

    All filesets for 61-06-021044_SP were found.

    All filesets for 61-06-031048_SP were found.

    All filesets for 61-05-041048_SP were found.

    All filesets for 61-04-081048_SP were found.

    All filesets for 61-03-081048_SP were found.

    All filesets for 61-03-091112_SP were found.

    All filesets for 61-04-091112_SP were found.

    All filesets for 61-05-051112_SP were found.

    All filesets for 61-06-041112_SP were found.

    Not all filesets for 61-06-051115_SP were found.

 

The culprit was the csm.hc_utils fileset from TL6 SP5. It was still at level 1.7.1.0 instead of the expected 1.7.1.1.

 

# instfix -ciqk "61-06-051115_SP" |grep ":-:"

61-06-051115_SP:csm.hc_utils:1.7.1.1:1.7.1.0:-:AIX 6100-06-05 Service Pack

 

I recommended that the csm.hc_utils 1.7.1.1 fileset be added to the AIX 6.1 lpp_source. The migration was attempted again and the client migrated to AIX 6.1 TLP6 SP5 successfully.  I also suggested they determine if this fileset was really used and/or needed (CSM is no longer supported/available starting with AIX 7.1 anyway).

 

And just when I thought all his problems were resolved, he replied with: “however upon trying to install these from the NIM server, I get errors on NIM”.

 

*********************************************************

errors:

0042-001 nim: processing error encountered on "master":                |

 |      0042-001 m_showres: processing error encountered on "master":       |

 |      0042-185 c_ch_nfsexp: Failed to link or copy /etc/.tmp.nim.exports. |

 |   12451894 to /etc/exports                                               |

 |           Check permissions and filesystem space

*********************************************************

 

Fortunately a quick look at the output from the df command highlighted the problem immediately.

He was out of space in the root file system. The very place that /etc/exports, and the NIM database (/etc/objrepos), reside.

 

# df -g

Filesystem    GB blocks      Free %Used    Iused %Iused Mounted on

/dev/hd4           2.50      0.00  100%     3388     1% /

/dev/hd2           4.50      1.74   62%    42150     4% /usr

/dev/hd9var        1.00      0.52   48%     3262     2% /var

/dev/hd3           4.00      3.84    5%       74     1% /tmp

/dev/hd1           0.50      0.37   27%      479     1% /home

/proc                 -         -    -         -     -  /proc

/dev/hd10opt       0.75      0.21   73%     5698     3% /opt

/dev/livedump      0.25      0.24    4%       17     1% /var/adm/ras/livedump

/dev/exportlv    136.25    124.03    9%    20128     1% /export

 

After cleaning up unwanted files in / and making sure there was plenty of free space, the error no longer appeared in future NIM operations.

 

 

 

I’ve been working with a customer recently on an issue with nimadm. They were attempting to migrate a system from AIX 5.3 to 7.1 using nimadm. The NIM client AIX level was 5.3 TL12 SP4 and the NIM master was running AIX 7.1 TL1 SP1.

 

lpar1 : / # oslevel -s

5300-12-04-1119

 

root@nim1 : / # oslevel -s

7100-01-01-1141

 

They were running the following nimadm command:

 

# nimadm -j nimadmvg -c lpar1 -s spotaix710101 -l lpp_sourceaix710101 -d hdisk1 -Y

 

The nimadm operation would always fail at phase 11:

 

+-----------------------------------------------------------------------------+
Executing nimadm phase 11.
+-----------------------------------------------------------------------------+
Cloning altinst_rootvg on client, Phase 3.
Client alt_disk_install command: alt_disk_copy -j -M 7.1 -P3 -d "hdisk1"
## Phase 3 ###################
Verifying altinst_rootvg...
alt_disk_copy: 0505-218 ATTENTION: init_multibos() returned an unexpected result.
Cleaning up.
forced unmount of /alt_inst/var/log
forced unmount of /alt_inst/var/log
forced unmount of /alt_inst/var
forced unmount of /alt_inst/var
forced unmount of /alt_inst/usr/local
forced unmount of /alt_inst/usr/local
forced unmount of /alt_inst/usr
forced unmount of /alt_inst/usr
forced unmount of /alt_inst/tmp
forced unmount of /alt_inst/tmp
forced unmount of /alt_inst/opt
forced unmount of /alt_inst/opt
forced unmount of /alt_inst/home
forced unmount of /alt_inst/home
forced unmount of /alt_inst/admin
forced unmount of /alt_inst/admin
forced unmount of /alt_inst
forced unmount of /alt_inst
0505-187 nimadm: Error cloning altinst_rootvg on client.
Cleaning up alt_disk_migration on the NIM master.
Cleaning up alt_disk_migration on client lpar1.
Client alt_disk_install command: alt_disk_install -M 7.1 -X
Bootlist is set to the boot disk: hdisk0 blv=hd5

 

We also found the init_multibos error in the /var/adm/ras/alt_disk_inst.log file on the NIM client:

 

Tue Nov 22 14:48:12 EETDT 2011

cmd: /ALT_MIG_SPOT/sbin/alt_disk_copy -j -M 7.1 -P3 -d hdisk1

Verifying altinst_rootvg...

alt_disk_copy: 0505-218 ATTENTION: init_multibos() returned an unexpected result.

Cleaning up.

 

Given that the error appeared to be related to init_multibos, we assumed the failure was due to some multibos checks being performed by alt_disk_copy on the client. The client system did not have an existing multibos standby instance. So, we tried two things: First we created a standby instance on the client (multibos –s –X) and re-tried the nimadm operation. This failed. Next we removed the standby instance (multibos –R) and re-tried the nimadm operation. This worked and the client then migrated to AIX 7.1 successfully. We re-tried the same operations (i.e. create standby instance, remove standby instance & nimadm) several times and each worked as expected.

 

So it appeared that the unofficial work around to this problem would be to create and then remove a standby multibos instance prior to the nimadm migrate. However, the customer has over 200 LPARs that they need to migrate to AIX 7.1. If possible they would really rather avoid this extra step in the AIX 7.1 migration plan. We’ve made contact with IBM support and are hoping they can assist us in identifying the root cause of the issue and provide us with an official solution to the problem.

 

And just yesterday we hit the same problem when migrating from AIX 6.1 to 7.1 using nimadm. I’ll update my blog with any progress we make with this problem. In the meantime, our unofficial work around will get us “out of hot water”!

 

UPDATE (14/12/2011): The simple fix is to remove the /bos_inst directory before attempting the AIX migration. i.e.

 

# rm –r /bos_inst

 

In my nimadm article I wrote:

• If you have a multibos image in rootvg, remove it. AIX migrations are not supported with multibos enabled systems. Ensure all rootvg LVs are renamed to their legacy names. If necessary, create a new instance of rootvg and reboot the LPAR. For example:

# multibos –sXp         # multibos –sX         # shutdown –Fr

 

Confirm the legacy LV names are now in use that is, not bos_.

# lsvg -l rootvg | grep hd | grep open         hd6           paging     80      160     2    open/syncd    N/A         hd8           jfs2log    1       2       2    open/syncd    N/A         hd4           jfs2       1       2       2    open/syncd    /         hd2           jfs2       7       14      2    open/syncd    /usr         hd3           jfs2       16      32      2    open/syncd    /tmp         hd1           jfs2       1       2       2    open/syncd    /home         hd9var        jfs2       8       16      2    open/syncd    /var         hd7           sysdump    8       8       1    open/syncd    N/A         hd7a          sysdump    8       8       1    open/syncd    N/A         hd10opt       jfs2       8       16      2    open/syncd    /opt

 

Remove the old multibos instance.

# multibos -R

 

Unfortunately, it appears that ‘multibos –R’ may not clean up the /bos_inst directory. If this directory exists the nimadm operation will most likely fail.

 

 

 

 

 

Do you use SSL with nimsh on AIX? No? Well, you might want to consider it. If you regularly use LPM to migrate AIX partitions from one server to another, you may have found that, on occasion, your NIM master has trouble communicating with its NIM clients afterwards. This is by design, as nimsh uses the NIM clients cpuid to authenticate with the NIM master. During an LPM operation, the cpuid of the NIM client changes and its possible the NIM master may reject the client as a result. This problem can occur even when CPU validation is disabled on the NIM master.

 

In the example below, I’ve LPM’ed a NIM client (750lpar1) to another server. Immediately afterwards, I’m able to execute a NIM command against the NIM client, from the NIM master (750lpar4). At this point the NIM client is configured with standard nimsh authentication i.e. no SSL.

 

NIM CLIENT (AFTER LPM):

[root@750lpar1]/ # uname -a

AIX 750lpar1 1 7 00F603CD4C00

 

[root@750lpar1]/ # uname -a

AIX 750lpar1 1 7 00F627664C00

 

[root@750lpar1]/var/adm/ras# echo HELLO > /var/adm/ras/nim.installp

 

NIM MASTER:

[root@750lpar4]/ # nim -o change -a validate_cpuid=no master

[root@750lpar4]/ # lsnim -l master | grep -i cpu

   validate_cpuid      = no

 

[root@750lpar4]/ # lsnim -l 750lpar1

750lpar1:

   class          = machines

   type           = standalone

   connect        = nimsh

   platform       = chrp

   netboot_kernel = 64

   if1            = 10_1_50 750lpar1 0

   cable_type1    = N/A

   Cstate         = ready for a NIM operation

   prev_state     = not running

   Mstate         = currently running

   cpuid          = 00F603CD4C00                << Notice that the cpuid is different.

 

[root@750lpar4]/ # nim -o showlog 750lpar1

HELLO

 

The cpuid is cached by the nimsh daemon, so the previous system id is retained in memory and passed to the NIM master, which allows the operation to complete successfully. But, if I restart the nimsh daemon, on the NIM client, I find that the NIM master is no longer able to communicate with the client.

 

[root@750lpar1]/ # stopsrc -s nimsh

0513-044 The nimsh Subsystem was requested to stop.

 

[root@750lpar1]/ # startsrc -s nimsh

0513-059 The nimsh Subsystem has been started. Subsystem PID is 6160610.

 

[root@750lpar4]/ nim -o define -t mksysb -a source=750lpar1 -a mksysb_flags=-e -a mk_image=yes -a server=master -a location=/export/mksysb/cg/750lpar1-mksysb 750lpar1-mksysb

0042-001 nim: processing error encountered on "master":

   0042-006 m_mkbosi: (From_Master) connect Error 0

 

0042-008 nimsh: Request denied - 750lpar4

 

[root@750lpar4]/ # nim -o showlog 750lpar1

0042-001 nim: processing error encountered on "master":

   0042-006 m_showlog: (From_Master) connect Error 0

 

0042-008 nimsh: Request denied - 750lpar4

 

[root@750lpar1]/var/adm/ras# grep match nimsh.log | grep CD

Wed Apr 27 20:51:12 2016        error: local value passed, '00F603CD4C00', does not match environment value '00F627664C00'

 

One way to work around this problem is to use the procedure outlined at the following link:

 

http://www.ibm.com/support/knowledgecenter/api/content/ssw_aix_71/com.ibm.aix.osdevice/lpm_nim.htm

 

“Migrating a NIM client by using LPM

 

When Live Partition Mobility (LPM) is used to move a machine from one physical server to another and the machine is defined as a Network Installation Management (NIM) client, the NIM administrator must update the cpuid attribute for the NIM client to reflect the new hardware value after the LPM migration completes. To update the cpuid attribute, complete the following steps:

 

On the NIM client, acquire the new cpuid ID by running the following command:

 

uname –a

 

On the NIM master, run the following command:

 

nim -o change -a cpuid=cpuid client”

 

However, there is a better way. Using nimsh, with SSL-enabled authentication, will prevent the checking of cpuid during nimsh service handling.  This is considered the recommended choice of operation (since the client/server can agree upon identity using the certificate information passed during the ssl handshake). Once the certificate is in place, the NIM master will disregard any cpuid validation and instead rely on the success of the SSL-handshake. This configuration will work well with LPM. If using standard nimsh, the limitation of cpuid updating would still apply (because NIM has no way of automatically updating a client once the value has changed).

 

Both the NIM master and client must be configured to support SSL-enabled authentication. To configure SSL-enabled authentication, we can use ‘nimconfig -c’ on the NIM master.

 

[root@750lpar4]/ # oslevel -s

7100-04-01-1543

 

[root@750lpar4]/ # nimconfig -c

0513-029 The tftpd Subsystem is already active.

Multiple instances are not supported.

NIM_MASTER_HOSTNAME=750lpar4

x - /usr/lib/libssl.so.0.9.8

x - /usr/lib/libcrypto.so.0.9.8

Target "all" is up to date.

Generating a 1024 bit RSA private key

.................++++++

....................................++++++

writing new private key to '/ssl_nimsh/keys/rootkey.pem'

-----

Signature ok

subject=/C=US/ST=Texas/L=Austin/O=ibm.com/CN=Root CA

Getting Private key

Generating a 1024 bit RSA private key

...++++++

....++++++

writing new private key to '/ssl_nimsh/keys/clientkey.pem'

-----

Signature ok

subject=/C=US/ST=Texas/L=Austin/O=ibm.com

Getting CA Private Key

Generating a 1024 bit RSA private key

.....................++++++

..........++++++

writing new private key to '/ssl_nimsh/keys/serverkey.pem'

-----

Signature ok

subject=/C=US/ST=Texas/L=Austin/O=ibm.com

Getting CA Private Key

 

[root@750lpar4]/ # lsnim -l | grep -i ssl

   ssl_support         = yes

 

[root@750lpar4]/ # /usr/samples/nim/ssl/certview -I /ssl_nimsh/certs/client.pem

certname= /ssl_nimsh/certs/client.pem

subject= /C=US/ST=Texas/L=Austin/O=ibm.com

issuer= /C=US/ST=Texas/L=Austin/O=ibm.com/CN=Root CA

notAfter=Apr 28 10:25:17 2017 GMT

 

[root@750lpar4]/ # /usr/samples/nim/ssl/certview -I /tftpboot/server.pem

certname= /tftpboot/server.pem

subject= /C=US/ST=Texas/L=Austin/O=ibm.com

issuer= /C=US/ST=Texas/L=Austin/O=ibm.com/CN=Root CA

notAfter=Apr 28 10:25:17 2017 GMT

 

To enable SSL nimsh on the NIM client, we can use the ‘nimclient –c’ command. You can fall-back to non-SSL nimsh, with ‘nimclient –C’.

 

[root@750lpar1]/# oslevel -s

7100-04-01-1543

 

[root@750lpar1]/var/adm/ras# nimclient -c

x - /usr/lib/libssl.so.0.9.8

x - /usr/lib/libcrypto.so.0.9.8

Received 2784 Bytes in 0.0 Seconds

0513-044 The nimsh Subsystem was requested to stop.

0513-077 Subsystem has been changed.

0513-059 The nimsh Subsystem has been started. Subsystem PID is 14942422.

 

[root@750lpar1]/var/adm/ras# cat nimsh.log

Fri Apr 29 23:10:45 2016        /usr/sbin/nimsh: NIM Service Handler started from SRC

Fri Apr 29 23:10:45 2016        no environment value for NIM_SECONDARY_PORT

Fri Apr 29 23:10:45 2016        value for hostname is 750lpar1

Fri Apr 29 23:10:45 2016        value for netaddr is: 10.1.50.31

Fri Apr 29 23:10:45 2016        value for route is net,-hopcount,0,,0 and gateway is 10.1.50.1

Fri Apr 29 23:10:45 2016        value for netif is en0

Fri Apr 29 23:10:45 2016        value for netmask is 255.255.255.0

Fri Apr 29 23:10:45 2016        obtained master's hostname: NIM_MASTER_HOSTNAME=750lpar4

 

Fri Apr 29 23:10:45 2016        obtained master's id: NIM_MASTERID=00F603CD4C00

 

Fri Apr 29 23:10:45 2016        value for machine id is 00F603CD4C00

Fri Apr 29 23:10:45 2016        Refreshing archive member /usr/lib/libssl.so.0.9.8 from /usr/lib/libssl.a ..

Fri Apr 29 23:10:45 2016        Refreshing archive member /usr/lib/libcrypto.so.0.9.8 from /usr/lib/libcrypto.a ..

 

Now I can LPM the NIM client to another server and even if I restart nimsh, the master can still communicate with the client. All thanks to SSL.

 

NIM MASTER:

 

[root@750lpar4]/ # lsnim -l 750lpar1

750lpar1:

   class          = machines

   type           = standalone

   connect        = nimsh (secure)

   platform       = chrp

   netboot_kernel = 64

   if1            = 10_1_50 750lpar1 0

   cable_type1    = N/A

   Cstate         = ready for a NIM operation

   prev_state     = not running

   Mstate         = currently running

   cpuid          = 00F603CD4C00

 

NIM CLIENT (AFTER LPM):

[root@750lpar1]/ # uname -a

AIX 750lpar1 1 7 00F603CD4C00

 

[root@750lpar1]/ # uname -a

AIX 750lpar1 1 7 00F627664C00

 

[root@lpar1]/ # stopsrc -s nimsh

0513-044 The nimsh Subsystem was requested to stop.

 

[root@lpar1]/ # startsrc -s nimsh

0513-059 The nimsh Subsystem has been started. Subsystem PID is 6160616.

 

[root@750lpar1]/var/adm/ras# tail -f nimsh.log

Fri Apr 29 23:13:33 2016        passing OpenSSL setting of 1

Fri Apr 29 23:13:33 2016        set symbol table

Fri Apr 29 23:13:33 2016         cert filename discovered: /ssl_nimsh/certs/750lpar4.0

Fri Apr 29 23:13:33 2016        ** OpenSSL FIPS mode enabled successfully

Fri Apr 29 23:13:33 2016        seed_prng

Fri Apr 29 23:13:33 2016        Loading certificates..

Fri Apr 29 23:13:33 2016        Loading private key file..

Fri Apr 29 23:13:33 2016        create BIO

Fri Apr 29 23:13:33 2016        - SSL Connection verified successfully -

Fri Apr 29 23:13:33 2016        sending ack to client

Fri Apr 29 23:13:33 2016        setting descriptors to include 2nd port

Fri Apr 29 23:13:33 2016        command to exec  __  /usr/lpp/bos.sysmgt/nim/methods/c_nimpush "/usr/lpp/bos.sysmgt/nim/methods/c_showlog" "-alocation=/var/adm/ras/nim.installp"

 

[root@750lpar4]/ nim -o define -t mksysb -a source=750lpar1 -a mksysb_flags=-e -a mk_image=yes -a server=master -a location=/export/mksysb/cg/750lpar1-mksysb 750lpar1-mksysb

 

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

                System Backup Image Space Information

              (Sizes are displayed in 1024-byte blocks.)

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

 

Required = 9457741 (9237 MB)    Available = 51653640 (50444 MB)

 

Creating information file (/image.data) for rootvg.

..etc..

 

 

 

Using NIM to install clients configured with SSL authentication

https://www.ibm.com/support/knowledgecenter/ssw_aix_71/com.ibm.aix.install/nim_install_ssl.htm

 

Using the certificate viewing file

https://www.ibm.com/support/knowledgecenter/ssw_aix_71/com.ibm.aix.install/sample_files_certificate.htm%23sample_files_certificate?lang=en

 

 

 

 

 

This little tip was passed on to me by a friendly IBM hardware engineer many years ago.

 

When entering a capacity on demand (CoD) code into a Power system, you can tell how many processors and how much memory will be activated, just by looking at the code you’ve given by IBM.

 

For example, the following codes, when entered for the appropriate Power system, will enable 4 processors (POD) and 64GB of memory (MOD). I can also tell* that once the VET code is entered, this system will be licensed for PowerVM Enterprise Edition (2C28).

 

System Type: 9117    Serial Number: 06-B719P Type Activation Code Posted Date (MM/DD/YYYY)  VET   F2FB60ERC4FF3DB50CA1F00002C28004177   04/30/2010   POD   FA94E589F2067F0C54680000000400419B   04/30/2010   MOD   B154E7097C231A85821200000064004102   04/30/2010

 

Activation type definitions
POD:	CUoD Processor Activation Code
MOD:	CUoD Memory Activation Code
TCOD:	On/Off CoD Enablement Code
TMOD:	On/Off CoD Memory Enablement Code
VET:	Virtualization Technology Code
	(PowerVM, Enterprise Enablement, WWPN, Active Memory Expansion)
STDP:	Standard Trial CoD Processor Activation Code
STDM:	Standard Trial CoD Memory Activation Code
STME:	Standard Trial Active Memory Expansion Code
EXCP:	Exception Trial CoD Processor Activation Code
EXCM:	Exception Trial CoD Memory Activation Code
USTA:	Utility CoD Enablement Code
USTO:	Utility CoD Termination Code
URPT:	Utility CoD Reporting Code
PAID:	Utility CoD PrePaid Code

0000 = Reset to base defaults (No PowerVM)
1xxx = Express
2c00 = Standard
2c20 = Enterprise

*Refer to the following link for more information on “How to tell which PowerVM Editions feature was ordered”: https://www-304.ibm.com/support/docview.wss?uid=isg3T1010860

 

You can obtain your CoD codes from the following website: http://www-912.ibm.com/pod/pod

 

 

======

 

UPDATE 12/9/2011: Script from Chris-R that collects CoD information for a system from the IBM CoD Website. Thanks Chris-R, nice job!

 

Done!

$ ./activations.pl 9117 10 06ebp
02 processors activated on 05/23/2011
024 GB memory activated on 05/23/2011
02 processors activated on 03/11/2011
016 GB memory activated on 03/11/2011
055 GB memory activated on 03/02/2011
06 processors activated on 02/22/2011
096 GB memory activated on 02/22/2011
01 processors activated on 01/12/2011
016 GB memory activated on 01/12/2011
06 processors activated on 03/17/2010
072 GB memory activated on 03/17/2010
19 processors activated on 03/16/2010
228 GB memory activated on 03/16/2010
================
TOTAL CPU=36 RAM=519168MB (507GB)

$cat activations.pl
#!/usr/bin/perl
#
# PoC Script to go out on the net to the IBM POD site and tally up activations for a given i or p Series machine
# Chris-R rutherfc@gmail.com
# v1.0 9/9/2011
#
# todo - add logic for processor deactivation - who uses that? IBM dont even publish the code on the pod site ;)
#
use LWP::UserAgent;
$ua = LWP::UserAgent->new;
$ua->agent("mozilla 8.0");
# $ua->proxy(['http'], 'http://proxy:8080/');
$ua->timeout(10);
use HTTP::Request::Common qw(POST);
if ($#ARGV != 2) {
print "usage: $0 MODEL XX XXXXX e.g $0 9119 83 9f6bf\n";
exit;
}
($model, $serial1, $serial2) = @ARGV;

##### main #####
get('http://www-912.ibm.com/pod/pod',"$serial2.htm");
html2txt("$serial2.htm","$serial2.txt");
total("$serial2.txt");
exit;

sub get # fakes a mozilla browser, fills in the CGI form and snags the returned page to a local html file
{
my $req = (POST $_[0],
["system_type" => $model,
"system_serial_number1" => $serial1,
"system_serial_number2" => $serial2 ]);
$request = $ua->request($req);
$activations = $request->content;
open(POD,">$_[1]");
print POD $activations;
close(POD);
}

sub html2txt # strips out the crap and converts the table to a local txt file to parse
{
open(HTML,"<$_[0]");
open(TXT,">$_[1]");
while (<HTML>) {
if (/<\/table>/) {$f = 0;};
if (/<th>Posted Date \(MM/) {$f = 1;};
if ($f == 1) {
# poor mans HTML::TableExtract - excuse my sed like perl....
s/<tr align="center">/:/g;
s/<[^>][^>]*>//g;
s/ //g;
s/\n//g;
s/:/\n/g;
print TXT $_;
};
};
close(TXT);
close(HTML);
}
sub total # totals up the de/activations to get totals
{
open(TXT,"<$_[0]");
$[ = 1; $\ = "\n";# set array base & output record separator
while (<TXT>) {
($code,$hex,$date) = split(' ', $_, -1);
if (/POD/) {
$p = substr($hex, 27, 2);
print $p . ' processors activated on ' . $date;
$pt = $pt + $p;
};
if (/MOD/) {
$r = substr($hex, 26, 3);
print $r . ' GB memory activated on ' . $date;
$rt = $rt + $r;
};
if (/RMEM/) {
$r = substr($hex, 27, 2);
print $r . ' GB memory activated on ' . $date;
$rt = $rt - $r;
};
};
print '================';
print 'TOTAL CPU=' . $pt . ' RAM=' . $rt*1024 . 'MB (' . $rt . 'GB)';
close(TXT);
}
</TXT></tr></th></HTML>