From: Yong S. Yi (ysyi@async.org)
Date: Wed Dec 18 2002 - 15:03:54 EST
Let me see if I can describe this clearly...
I have two Ultra Enterprise 220R in identical configuration, as follows:
* 2 x 450MHz CPUs
* 1024MB memory
* 2 x X6729A (fibrechannel HBA); one '97 revision, one '99 revision,
installed in the same physical PCI slot configuration
There are also two StorEdge A5200s, each connected to the machines as
illustrated below (using my masterful ASCII line drawing):
+-----+ +-----+
| db0 | | db1 |
+-----+ +-----+
| | / |
| \ / |
\ `----------/-. |
\ / \ |
\ ,-------' \ |
+-----+ +-----+
|disk0| |disk1|
+-----+ +-----+
This configuration is intended to serve a shared diskset configuration using
Solstice DiskSuite 4.2.1, under Solaris 8.
An interesting point to note is that the '97 revision of the X6729A uses the
Sun-shipped 'ifp' ("Sun Fibre Channel Arbitrated Loop Device Driver")
driver, while the '99 revision uses QLogic's QLA2100 driver (version 3.03).
I should also mention right now that these machines were installed in the
identical fashion, at the same time, using a custom JumpStart with finish
scripts which do everything, meaning that the likelihood of having
configured something a bit differently on each host is quite slim.
I got the disk devices (under the 'sd' driver) on the '99 revision of the
HBA to show up by adding additional target entries into /kernel/drv/sd.conf.
There are plenty of entries, and all of the disks (AFAIK) show up under
format(1M):
db1# tail -2 /kernel/drv/sd.conf
name="sd" class="scsi"
target=128 lun=0;
db1# format
Searching for disks...
AVAILABLE DISK SELECTIONS:
0. c0t0d0 <SUN18G cyl 7506 alt 2 hd 19 sec 248>
/pci@1f,4000/scsi@3/sd@0,0
[...]
6. c1t36d0 <SUN9.0G cyl 4924 alt 2 hd 27 sec 133>
/pci@1f,4000/scsi@4/sd@24,0
7. c1t37d0 <SUN9.0G cyl 4924 alt 2 hd 27 sec 133>
/pci@1f,4000/scsi@4/sd@25,0
[...]
28. c2t6d0 <SUN9.0G cyl 4924 alt 2 hd 27 sec 133>
/pci@1f,4000/SUNW,ifp@5/ssd@w220000203719fe99,0
29. c2t7d0 <SUN9.0G cyl 4924 alt 2 hd 27 sec 133>
/pci@1f,4000/SUNW,ifp@5/ssd@w220000203719f7f3,0
[...]
Disks #6 and #7 are connected to the '99 revision of the HBA (scsi), and
disks #28 and #29 are connected to the '97 revision of the HBA (ifp). Now,
everything seems to look okay for the disks on the '99 revision, however, on
the OTHER host, I see:
db2s:~# format
Searching for disks...done
AVAILABLE DISK SELECTIONS:
0. c0t0d0 <Symbios-StorEDGEA1000-0205 cyl 8615 alt 2 hd 64 sec 64>
/pci@1f,4000/scsi@3/sd@0,0
[...]
6. c1t36d0 <SUN9.0G cyl 4924 alt 2 hd 27 sec 133>
/pci@1f,4000/scsi@4/sd@24,0
7. c1t37d0 <SUN9.0G cyl 4924 alt 2 hd 27 sec 133>
/pci@1f,4000/scsi@4/sd@25,0
[...]
28. c2t6d0 <SUN9.0G cyl 4924 alt 2 hd 27 sec 133>
/pci@1f,4000/SUNW,ifp@5/ssd@w210000203719fe99,0
29. c2t7d0 <SUN9.0G cyl 4924 alt 2 hd 27 sec 133>
/pci@1f,4000/SUNW,ifp@5/ssd@w210000203719f7f3,0
[...]
That might look identical, but in the eyes of DiskSuite's shared diskset
feature, it is not. Notice the difference:
...ssd@w220000203719fe99,0
...ssd@w210000203719fe99,0
^-- right here
Here's the catch: at one time when these were connected through only the '97
revision of the X6729A (ifp), they showed up to be identical! Shared
disksets were working on that configuration. However, after moving the cards
around to install the new '99 X6729A's (and re-installation of O/S), it's
slightly different.
I don't think I understand the Solaris device naming / addressing well
enough, or much at all. I've tried hand-editing /etc/path_to_inst (after
making backups of the originals, of course), but no luck there.
Not sure if I gave too much unnecessary details, or too little.
If you happen to know how to resolve this issue, or have any other sorts
of insights, I would greatly appreciate your input.
-- Yong S. Yi <ysyi@async.org> PGP Key ID 0x9C760BD7 _______________________________________________ sunmanagers mailing list sunmanagers@sunmanagers.org http://www.sunmanagers.org/mailman/listinfo/sunmanagers
This archive was generated by hypermail 2.1.7 : Wed Apr 09 2008 - 23:25:29 EDT