Question about special file...

[OLIVA_1]

Hello,

I have 2 identical servers L3000 and 2 identical disk bays "HP Disk Sytem 2300".

The first disk bay is connected to the first server and the second disk bay to the second server. Each disk bays is conected with 2 SCSI cables.

When I use ioscan -fnCdisk I can see a list of all the disks through 2 path... at this point all is ok.

But why I have these paths on the first server :
/dev/dsk/c5txd0
/dev/dsk/c7txd0

and these others ones on the second serveur :
/dev/dsk/c7txd0
/dev/dsk/c9txd0

Someone can help me to change c5 to c9 or c9 to c5... in order to have exactly the same paths on both servers ?
Why this controller number is different ?

Thanks for you help.

[Steven E. Protter]

Shalom,

It has to do probably with one of two factors:

The scsi id of the controller

The connection to the disk bay.

One machine connects at one end of the scsi chain, the second at the opposite end.

I'm guessing you have four ports on the back. One has a short cable connecting two ports and the other two connect to your machines.

You may have gotten the connections wrong and may need to refer to documentation for proper connnection.

SEP

[OLIVA_1]

Thanks Steven.

I have exactly the same connection...
So do you know how can I check the SCSI ID controller ?

Thanks.

[James R. Ferguson]

Hi Oliva:

The hardware numbers are assigned when devices are first installed scanned by 'insf'. The order in which devices are seen determines the original ordinal numbering. This information is stored in an 'ioconfig' file which is then read at subsequent boots by the kernel.

There is no need to change the the device files. The process to do so is somewhat less the straightforward. More importantly, your view of these files is generally at another (higher) layer, as for instance, a 'vgdisplay -v vgXX'.

Regards!

...JRF...

[Mridul Shrivastava · Accepted solution]

I have given the procedure for the same in the below mentioned thread:

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1027043

Have a look.

[A. Clay Stephenson]

The instance number is determined by the order in which new hardware is discovered. This means that when the OS was initially loaded the hardware was not identical.

It gets more complicated to change the instance numbers if one of these are boot devices; if they are simply external data disks then the task is much earier.

[Mridul Shrivastava]

The ioconfig command provides the mapping between instance numbers used
by the kernel and the information the I/O system uses to communicate with
peripheral devices (hardware paths). Two copies are maintained
(/stand/ioconfig and /etc/ioconfig).

At boot time the ioconfig information is stored in the io_tree kernel data
structure (see ioinit(1M)). The only purpose of the ioconfig is to maintain
configuration information when the system is not running. Even if hardware is
removed from the system all mappings keep in place. This guarantees that no
new device file names will appear after such changes. If removed hardware is
added back to the system the original mapping can be reused, since it is still
present in the ioconfig files.

Usually we want to change mappings for disk and lan devices. For lan devices
we change directly the corresponding lan instance numbers. For disk devices we
need to take care of the ext_bus instance numbers. The numbers of
such 'External Busses' (aka card instances) are responsible for the 'c'
numbers being part of disk device names.

Look at the following extract of an ioscan -fn:

ext_bus 3 2/0/1 c720 CLAIMED INTERFACE Built-in SCSI
target 0 2/0/1.3 tgt CLAIMED DEVICE
target 1 2/0/1.5 tgt CLAIMED DEVICE
disk 4 2/0/1.5.0 sdisk CLAIMED DEVICE SEAGATE
ST15150N
/dev/dsk/c3t5d0 /dev/rdsk/c3t5d0

The ext_bus instance number (3) is responsible for the 'c3' in
'c3t5d0'. The target (t5) and the LUN (d0), which affect the rest of
the name, are not changeable by software. Instead they map directly to the
underlying hardware configuration.


WARNING: Remapping instances is inherently dangerous and may result in an unbootable system, if not performed with care. Thus it is advisable to take a backup (e.g. using make_tape_recovery) of the system before attempting any of these procedures. It is also advisable to save the current
/etc/ioconfig file, e.g to
/etc/ioconfig.bak. Usually it is possible
to recover from failures by copying that file back to /etc/ioconfig and
/stand/ioconfig before rebooting.


This procedure requires one reboot and works without additional tools.

1. Extract a configuration template from the current ioscan output.
Execute the following command:

# ioscan -f | grep -e INTERFACE -e DEVICE | \
grep -v target | \
awk '{print $3, $1, $2}' > /infile

2. Edit /infile and change the ext_bus and lan instances as desired.
No class is allowed to get more than one line for the same instance!

3. Bring down the system gracefully to run level 1.

# init 1

4. Apply the ioconfig change:

# /sbin/ioinit -f /infile -r

The system will reboot immediately if the change is successful.
Warnings like 'Input is identical to kernel' can be ignored.

If unsuccessful, the most likely error to happen is:
"ioinit: Instance number X already exists for class XXX"

The problem is that your desired instance assignment conflicts with
an existing instance number. If that instance is bound to hardware
that is no longer visible in ioscan, then you are in trouble and
need to perform the Procedure II or III.

5. Once the system reboots, verify that all the instance numbers
were changed as expected. It may be necessary to re-import volume
groups to ensure that /etc/lvmtab contains the correct
entries. The lan configuration may need to be changed also.

Be sure to have the ioinit(1M) patch installed:
10.20: [PHCO_16407/PACHRDME/English] (or greater)
11.00: [PHCO_12555/PACHRDME/English] (or greater)

If the above mentioned procedure fails then try this one:

Reliable, requires two reboots and works without additional tools.

1. Extract a configuration template from the current ioscan output.
Execute the following command:

# ioscan -f | grep -e INTERFACE -e DEVICE | \
grep -v target | \
awk '{print $3, $1, $2}' > /infile

Make sure to store infile to the root file system!

2. Edit /infile and change the ext_bus and lan instances as desired.
No class is allowed to get more than one line for the same instance!

3. Move away the current ioconfig files and Shutdown/Reboot:

# mv /stand/ioconfig /stand/ioconfig.sav
# mv /etc/ioconfig /etc/ioconfig.sav
# shutdown -ry 0

4. Due to the missing ioconfig files the system will come to an
ioinitrc prompt. Now recreate new ioconfig files from scratch.
This prevents you from running into possible assignment conflicts.

(in ioinitrc)# /sbin/ioinit -c

5. Apply the ioconfig change with your prepared infile:

(in ioinitrc)# /sbin/ioinit -f /infile -r

The system will reboot again now if the change was successful.
Warnings like 'Input is identical to kernel' can be ignored.

6. Once the system reboots, verify that all the instance numbers
were changed as expected. It may be necessary to re-import volume
groups to ensure that /etc/lvmtab contains the correct
entries. The lan configuration may need to be changed also.