Recently my employer has moved from an old DMX3 SAN to a newer VMAX SAN. The procedure was worked out, and everything was moved over (fairly smoothly). Some exceptions were the BIG VG’s being maxed at the Total PV sizes, and unable to increase due to the times factor of the Volume Group which couldn’t be reduced. Some of these VG’s could be fixed up by migrating the Volume Group from Big VG to Scalable VG. However, in the case of oracle, another issue was found. Some of the Volume Groups were initially created as a “normal Volume Group”. Now what this meant is when the LVs were created for oracle (as raw FSs) they had the switch of “mklv -T O”. This indicates that the LVCB (Logical Volume Control Block) will NOT occupy the first block of the logical volume. It has a subtype identifier of DS_LVZ (or zero-byte). Problem is, that option is ignored with Normal VGs and Scalable VGs. Hence, the LV will be created with no errors presented. This involved converting the VG, and migrating the data. This information was discussed in detail in this post.
Overall, the process was completed with a couple of hickups. Everything was fine, however, there is the odd issue which has cropped up. The latest is in regards to the migration of the rootvg from old disks to new disks (in my case LUNs). This was apparent when looking at the mksysb logs. One of the servers wasn’t being backed up. It complained that the resource file didn’t exist. Naturally, I went to add the resource back in (using the fast path of smit nim_mkres), which ended in a failure.
Command: failed stdout: yes stderr: no
0042-001 nim: processing error encountered on "master":
0042-001 m_mkbosi: processing error encountered on "server_153":
0301-150 bosboot: Invalid or no boot device specified!
usage: bosboot {-a | -v} [-d device] [-p proto] [-k kernel] [-l lvdev]
[-b file] [-M serv|norm|both] [-D|-I] [-LTq]
Where:
-a Create boot image and write to device or file.
-v Verify, but do not build boot image.
-d device Device for which to create the boot image.
-p proto Use given proto file for RAM disk file system.
-k kernel Use given kernel file for boot image.
-l lvdev Target boot logical volume for boot image.
-b file Use given file name for boot image name.
-D Load kernel debugger.
-I Load and Invoke kernel debugger.
-M norm|serv|both Boot mode - normal or service.
-T platform Specifies the hardware platform type.
-q Query disk space required to create boot image.
-L Enable MP locks instrumentation.
Upon logging into the server and perusing about a few things were noticed. Most notably the boot device seemed fine, however, re-creating wasn’t such an easy task.
server_153:~# bootlist -m normal -o
hdisk2 blv=hd5
server_153:~# ls -l /dev/ipl* /dev/hdisk2 /dev/rhd5 /dev/rhdisk2
brw------- 1 root system 13, 3 Aug 09 14:21 /dev/hdisk2
crw-rw---- 2 root system 10, 1 Sep 29 2010 /dev/ipl_blv
crw------- 1 root system 13, 3 Aug 09 14:04 /dev/ipldevice
crw-rw---- 2 root system 10, 1 Sep 29 2010 /dev/rhd5
crw------- 2 root system 13, 3 Jun 07 00:12 /dev/rhdisk2
server_153:~# bosboot -ad /dev/hdisk2
bosboot: Boot image is 43119 512 byte blocks.
As the ipldevice had a different timestamp, I decided to remove and re-create the links.
rm /dev/ipldevice
rm /dev/ipl_blv
ln /dev/rhdisk2 /dev/ipldevice
ln /dev/rhd5 /dev/ipl_blv
That part worked, now to try creating the boot disk:
bosboot -ad /dev/ipldevice
301-150 bosboot: Invalid or no boot device specified!
usage: bosboot {-a | -v} [-d device] [-p proto] [-k kernel] [-l lvdev]
[-b file] [-M serv|norm|both] [-D|-I] [-LTq]
Where:
-a Create boot image and write to device or file.
-v Verify, but do not build boot image.
-d device Device for which to create the boot image.
-p proto Use given proto file for RAM disk file system.
-k kernel Use given kernel file for boot image.
-l lvdev Target boot logical volume for boot image.
-b file Use given file name for boot image name.
-D Load kernel debugger.
-I Load and Invoke kernel debugger.
-M norm|serv|both Boot mode - normal or service.
-T platform Specifies the hardware platform type.
-q Query disk space required to create boot image.
-L Enable MP locks instrumentation.
Apparently, that aspect isn’t working so well. I don’t believe this system was ever rebooted after the SAN Migration, so I would expect a reboot would be required. Hopefully a recovery session won’t be required to fix the mess. Time will tell, once an outage window is granted. This seems to be an over-sight or bug on IBMs part. For the mksysb operation looks at the boot image as recorded from the last boot. As the system was migrated, the old boot device no longer exists (was rmdev’d and fibre optic cables to old SAN severed). Hence, a simple reboot should resolve this issue.