We came across this issue,                                              

IZ58496 NIMADM TO 61 DOES NOT CREATE A /DEV/HD11ADMIN APPLIES TO AIX 6100-03                                                                 

while performing some AIX 5.3 to 6.1 migrations with nimadm.            

This was resolved by applying SP2 for TL3 on the NIM master.            

However, we then noticed that the hd11admin LV is being created as type of jfs not jfs2.                                                   

We worked around this problem by creating a custom image.data, changing the jfs type to jfs2 and using this as a NIM image_data resource to     

nimadm (see example below).                                                                 

This worked OK in our environment:                                                       

NIM master: 6100-03-02-0939                                             

---                                                                     

NIM client prior to migration: 5300-07-05-0831                          

NIM client after migration: 6100-03-01-0921                             

Creating a custom image.data:

1. On bxaix87(the NIM client), create a new image.data file. Copy it to the NIM master.

# mkszfile

# scp /image.data bxaix85:/tmp/cg

2. On bxaix85 (the NIM master), edit the image.data file, add hd11admin and create a new NIM image_data resource.

# cd /tmp/cg

# vi image.data

lv_data:

        VOLUME_GROUP= rootvg

        LV_SOURCE_DISK_LIST=

        LV_IDENTIFIER=

        LOGICAL_VOLUME= hd11admin

        TYPE= jfs2

        MAX_LPS= 512

        COPIES= 1

        LPs= 1

        STALE_PPs= 0

        INTER_POLICY= minimum

        INTRA_POLICY= center

        MOUNT_POINT= /admin

        MIRROR_WRITE_CONSISTENCY= on/ACTIVE

        LV_SEPARATE_PV= yes

        PERMISSION= read/write

        LV_STATE= opened/syncd

        WRITE_VERIFY= off

        PP_SIZE= 64

        SCHED_POLICY= parallel

        PP= 4

        BB_POLICY= relocatable

        RELOCATABLE= yes

        UPPER_BOUND= 32

        LABEL= /admin

        MAPFILE=

        LV_MIN_LPS= 1

        STRIPE_WIDTH=

        STRIPE_SIZE=

        SERIALIZE_IO= no

        FS_TAG=

        DEV_SUBTYP=

…

fs_data:

        FS_NAME= /admin

        FS_SIZE= 262144

        FS_MIN_SIZE= 32768

        FS_LV= /dev/hd11admin

        FS_JFS2_BS= 4096

        FS_JFS2_SPARSE= yes

        FS_JFS2_INLINELOG= no

        FS_JFS2_SIZEINLINELOG= 0

        FS_JFS2_EAFORMAT= v1

        FS_JFS2_QUOTA= no

        FS_JFS2_DMAPI= no

        FS_JFS2_VIX= yes

        FS_JFS2_EFS= no

# smit nim_mkres

image_data      = config file used during base system installation

                             Define a Resource

Type or select values in entry fields.

Press Enter AFTER making all desired changes.

                                                        [Entry Fields]

* Resource Name                                      [cg_image_data]

* Resource Type                                       image_data

* Server of Resource                                 [master]                   +

* Location of Resource                              [/tmp/cg/image.data]       /

# lsnim -t image_data

cg_image_data     resources       image_data

# lsnim -l cg_image_data

cg_image_data:

   class       = resources

   type        = image_data

   Rstate      = ready for use

   prev_state  = unavailable for use

   location    = /tmp/cg/image.data

   alloc_count = 1

   server      = master

3. Perform the migration with the -i flag on the NIM master.

# nimadm -i cg_image_data -j nimadmvg -c bxaix87 -s spotaix61031 -l lppsourceaix61031 -d "hdisk1" -Y

4. The hd11admin LV is created with type of jfs2 on the NIM client.

# lsvg -l altinst_rootvg | grep hd11

alt_hd11admin       jfs2       1       1       1    open/syncd    /alt_inst/admin

Using this procedure means we would have to create a new image.data resource for every NIM client. Or just overwrite the file each time.

This is a known problem. Apparently APAR IZ45287 will resolve this issue for AIX 6.1 TL03.

According to the support guys, only one other customer has reported this problem.

So I thought I’d share this with you in order to workaround or avoid it, when it’s time for you to upgrade to AIX 6.1.