Device File Names & OS Upgrade

[Justin Willoughby]

I am upgrading my MC/SG cluster to 11.00 from 10.20

One problem I have had is the devices not being the same after the upgrade. I was able to fix the lan cards with a ioinit command.

For the shared disks I also fixed the instance # with an ioinit (using an infile I created) and now the instance are correct the device names in /dev/dsk are not. How can I fix this? After I fixed the instance # I rebooted removed /dev/dsk/* /dev/rdsk/* and did a insf -C disk -e but the device names are still not right.

Any help would be appreciated!

- Justin

[Christopher McCray_1]

Hello,

Check out the -I option wth insf

Hope this helps

Chris

[James R. Ferguson]

Hi Justin:

Rather than fool with instance numbers, which are (usually) meaningless, for your disk devices simply 'vgexport' and 'vgimport' your volume groups using the new paths.

Regards!

...JRF...

[A. Clay Stephenson · Accepted solution]

Unless you are using true raw disk io (not LVM raw disks) this really doesn't matter. You should simply do a vgimport using the new device nodes. The device numbers changes when I/O boards have been added, deleted, or moved since the OS was initially installed. If you are using raw disk io then you will have to use ioscan -M ... -H ... to set the desired instance for the controller and then recreate the affected disk device nodes. If you are using true raw disk io, it's always better to add a layer of indirection via symbolic links so that this is a very simple task.

e.g. your oracle file might be /u01/oradata/file01.dbf; you then symbolically link that to a raw disk (/dev/rdsk/c4t6d0).

[Justin Willoughby]

A. Clay,

So even though the device numbers are different I can still use a vgexport map file from the other node that has different device names? Yes these are LVM disks and not raw.

- Justin

[James R. Ferguson]

Hi (again) Justin:

Don't confuse "map" with the list of paths. You can 'vgexport' with the '-f outfile' option to collect the pv_paths into a file as they exist. Then, you can edit this file and apply it to 'vgimport' using '-f infile'. This is very handy when you have a large number of paths to a volume group. It avoids having to specify them on the command line.

A "map" file applies to logical volume names and can optionally contain a VGID to assist in 'vgimport'. If you have standard logical volume names within your volume group (lvol1, lvol2, etc.) then the mapfile is superfluous in controlling naming of the logical volumes. See the ma pages for 'lvcreate' for more information on this.

Regards!

...JRF...

[Christopher McCray_1]

Hello

First off, apologies to A. Clay for answering this. Yes you can use a map file from vgexport. Use the -s option, which saves the VGID, and when you import, use the -s, which "scans" the disks for the matching VGID. Alternatively, you can merely specify each individual disk with the vgimport command.

See man for vgimport for more details

Chris

[Nick Wickens]

Hi Justin

Don't forget that you will need to peform the vgimport for volumes in your service guard cluster to all nodes in the cluster.

[Stephen Doud]

Hello Justin,

This topic is dealt with in document UXSGKBRC00005958 - "Changing I/O Instance Numbers On A ServiceGuard Server "

-s.