Sun Server with DiskSuite to XP512???

[Patrick Eagan]

Hello,

Sorry, I first submitted as an answer and ment it to be a question.

In reguards to attaching a Solaris system to an XP512. Here is the problem I am having.
The system is a Sun Enterprise 3000 with
sbus JNI cards. I can see the disk fine
with "format". The problem is that when I go
to use the Sun Volume Management software
(DiskSuite) I get the following error creating volumes
ssrv038h# metainit -f d1 2 1 c2t4d0s0 1 c2t4d1s0
metainit: ssrv038h: c2t4d1s0: overlaps with device in d1
(a stripe called d1 that spans c2t4d0s0 and c2t4d1s0)

Here is what they look like in format:
4. c2t4d0
/sbus@2,0/fcaw@2,0/sd@4,0
5. c2t4d1
/sbus@2,0/fcaw@2,0/sd@4,1

I am also working with SUN to try to find the correct answer.
It is documented that Sun is reading all the "non-Sun" disk as the same serial number, thus causing confusion when it tried to assigne uniqueness.

Just hoping that someone else has seen this and found a workaround.

Attempted entries in /kernel/drv/sd.conf to solve problem:
sd-config-list=
"HP-OPEN-E-SUN-0116", "unsupported-hack";
unsupported-hack=1,0x8,0,0,0,0,0;
sd-config-list=
"HP-OPEN-E-SUN", "unsupported-hack";
unsupported-hack=1,0x8,0,0,0,0,0;
sd-config-list=
"HP OPEN-E-SUN-0116", "unsupported-hack";
unsupported-hack=1,0x8,0,0,0,0,0;
sd-config-list=
"HP OPEN-E-SUN", "unsupported-hack";
unsupported-hack=1,0x8,0,0,0,0,0;
(sort of recommended by SUN)

Thanks,
Pat

[Duncan Edmonstone]

Not sure of the answer to your question Patrick, but wht are youi trying to stripe using ODS when this can be done (and already be done) on the XP512? The s/w striping will almost inevitably be slower than the h/w, and in some cases striping an already striped RAID array can confuse the cahing algorithms on the arrya, reducing performance even more...

HTH

Duncan

[Patrick Eagan]

My experience with the XP is limited.
The guys that manage the array have set it up
as 36 x 13GB LUNS (this is their standard on our HP SAP systems) The problem is that I need some partitions greater than 13GB, up to 35GB.
I was told they could make it just one disk, but, I need more than 7 slices that ODS provides for my configuration. I will check to see if maybe we could make the disks bigger than the current 13GB OPEN-E's. All else fails I guess we could create the filesystems without any management software. (but still would like to have an alternate-path)

Thanks

[Duncan Edmonstone]

Patrick, I guess I misunderstood... It seems you just want a bunch of disks 'concat'd together into one big disk, and your not attempting to stripe at all... I guess it must be some of the ODS jargon confusing me.

Duncan

[Lowell Dale]

This is just a note to Duncan's statement and question on the striping. To say that the XP already stripes is somewhat of a naive statement. The array group in which the ldev/luns are created are in fact 'striped' across the disks in that array group. However, we take it one step further in our environments and when building volume groups in our logical disk manager we stripe across ldevs/luns that are not bound by an array group or domain. So a logical volume may actually span 10 luns/ldevs, which may span 40 disks instead of 4 because of of the disperse method we're using.

So thay may answer your question the next time it comes up (as to why stripe beyond what's already 'striped' by the XP)

[Duncan Edmonstone]

Lowell,

You are correct... I should have considered that (doffs cap and stares at shoes....)

Cheers

Duncan

[Trevor Roddam_1]

This may be off the mark but;

Do you have alternate paths to the disks on the XP from the E3000?
If so disable it as, Disk Suite isn't really able to cope.

Next, talk to SUN first then HP. HP do install these systems (XP's) with Solaris and are keen to make it work.
I've used SUN E systems onto HDS PtP; HP OEM HDS to the XP series so it should be possible.

Veritas Volume Manager is a must with Solaris and alternate paths at this level. It makes a difference in how the FC connected disks are seen and used.
We had to fiddle the way Solaris configured the device files at boot and update FC card firmware for it to work.
I just can't remember the tweek.

Sorry that I've not answered directly, but at least it should be possible.

[Patrick Eagan]

From everything I am seeing from the people I have talked to the problem is only with the Sun DiskSuite software reading the SCSI ids of the disks. Veritas from what I read, does not work that way. The problem is that to run Veritas would cost extra $$'s.
Multipathing is not important since the systems are Development and Disaster Recovery at a remote site (and we only have limited connections to the XP)
I am still working with HP and SUN to resolve.

[Vincent Fleming]

You are correct when you say the problem is Disk Suite... Sun has always taken a very proprietary stance with volume managers - even the version of Veritas they distribute (a "lite" version) disables lots of features when used with "non-Sun" disks. For example, you cannot RAID5 on non-Sun JBOD drives, and multipathing does not work with non-Sun drives.

You should do yourself a favor and just buy a copy of Veritas VM... it works just fine.

Good luck!

[Patrick Eagan]

The fix was just the following entry into the /kernel/drv/sd.conf file
sd-config-list=
"HP OPEN-E ", "unsupported-hack";
unsupported-hack=1,0x8,0,0,0,0,0;

The correct format was found by using
format -e -> {pick disk} -> scsi -> inquiry and looking at the actual SCSI header, and making sure you get all the spaces(20's)
SUN mentions that the text field is "8Characters-vendor+16Characters-product" these may be the max.
Inquiry:
00 00 02 02 73 00 00 02 48 50 20 20 20 20 20 20 ....s...HP
4f 50 45 4e 2d 45 20 20 20 20 20 20 20 20 20 20 OPEN-E
30 31 31 36 30 34 30 30 37 38 32 45 30 30 34 43 01160400782E004C
20 31 45 20 01 01 01 01 00 00 00 00 00 00 00 00 1E ............
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
01 06 05 00 04 00 ff 00 20 00 00 e0 69 40 6f 7d ........ ...i@o}
10 00 00 e0 69 40 6f ....i@o

[Daping Xia]

Pat,

I ran into the same issue as you did. It seems to me that you find the solution. Would you mind sharing it?

Thanks!

[Patrick Eagan]

The real fix was putting the correct entry in the /kernel/drv/sd.conf file. with out this all disks are seen with the same ID

Here it is with "x" as a blank space. (this board seems to truncate spaces in previous replys) see 5/31/02 reply for how this was found.


sd-config-list=
"HPxxxxxxOPEN-Exxxxxxxxxx", "unsupported-hack";
unsupported-hack=1,0x8,0,0,0,0,0;