Thank to all who answered (full list at the end):
With the hint of Rogerio Rocha I found the solution. My mistake was: I attempted
to get the "backup"-Server to behave like the Server (The owner of the
array). This didn't work. I should have to try it vice versa (- Stubbornedly I
didn't tried it vice versa before, to show SUN that there is elsewhere a bug
making the difference.;-]). The "Backup"-Server has "wholes" in the numbering of
the ssd, the Server not (all other lines of the path_to_inst-s were the same ).
So I
1. copied the path_to_inst of the "backup"-Server to the original Server,
2. destroyed all metadevices and metaset, and dev/ices hinting to the array and
3. built the dev/ices again with boot -rs.
4. Than I created the metaset again. The Server and the "backup"-Server became a
host of the same set. Of course the server as the owner.
5. After creating the metadevices again all looks fine.
- be carefull with this procedure -
Bernhard Fank
-----------------------------------------------------------------
My original question:
>Hi sun-managers,
>2 E3000-Server should backup one another. For this reason they are
>connected via Fibre Channel on a SSA112. But the minor-numbers of the
>disks on the SSA112 are differing (SDS for example is using the
>driver-numbers). The servers have the same configuration.
>Analyzing the problem:
> 1. Usual solution: We deleted the path_to_inst and the according
> /dev's and /devices, rebuilded the path_to_inst, /dev's and /devices
> with boot -ar.
> --> No change in minor-numbers.
> 2. Proof the hardware: We put the local boot-disks of the one server
> into the other and booted this server.
> --> The server couldn't use the minor-numbers of the other.
>We couldn't find a solution with SUN's staff (silver contract). They
>advised us to disconnect the array and optical modules and reconfigure,
>connect the empty array and reconfigure. Afterwards we should fill the
>empty array disk-layer by disk-layer and reconfigure each time.
>We can't stop the system for so a long time and we don't think this is
>a solution to our problem. See Analyzing above.
>I would be very pleased, if you could help us. Further description
>below. ....
>----------------------------------------------------------------------
>Example out of merged and sorted path_to_inst (the two Hosts are
>called krz10 and krz18 - the first 4 Addresses don't differ):
>krz10 /sbus@2,0/SUNW,soc@d,10000/SUNW,pln@a0000000,802949/ssd@0,1 1
>ssd
>krz18 /sbus@2,0/SUNW,soc@d,10000/SUNW,pln@a0000000,802949/ssd@0,1 1
>ssd
>krz10 /sbus@2,0/SUNW,soc@d,10000/SUNW,pln@a0000000,802949/ssd@0,2 2
>ssd
>krz18 /sbus@2,0/SUNW,soc@d,10000/SUNW,pln@a0000000,802949/ssd@0,2 2
>ssd
>krz10 /sbus@2,0/SUNW,soc@d,10000/SUNW,pln@a0000000,802949/ssd@0,3 3
>ssd
>krz18 /sbus@2,0/SUNW,soc@d,10000/SUNW,pln@a0000000,802949/ssd@0,3 3
>ssd
>krz10 /sbus@2,0/SUNW,soc@d,10000/SUNW,pln@a0000000,802949/ssd@0,4 4
>ssd
>krz18 /sbus@2,0/SUNW,soc@d,10000/SUNW,pln@a0000000,802949/ssd@0,4 4
>ssd
>krz10 /sbus@2,0/SUNW,soc@d,10000/SUNW,pln@a0000000,802949/ssd@1,0 5
>ssd
>krz18 /sbus@2,0/SUNW,soc@d,10000/SUNW,pln@a0000000,802949/ssd@1,0 16
>ssd
>krz10 /sbus@2,0/SUNW,soc@d,10000/SUNW,pln@a0000000,802949/ssd@1,1 6
>ssd
>krz18 /sbus@2,0/SUNW,soc@d,10000/SUNW,pln@a0000000,802949/ssd@1,1 17
>ssd
>krz10 /sbus@2,0/SUNW,soc@d,10000/SUNW,pln@a0000000,802949/ssd@1,2 7
>ssd
>krz18 /sbus@2,0/SUNW,soc@d,10000/SUNW,pln@a0000000,802949/ssd@1,2 18
>ssd
>krz10 /sbus@2,0/SUNW,soc@d,10000/SUNW,pln@a0000000,802949/ssd@1,3 8
>ssd
>krz18 /sbus@2,0/SUNW,soc@d,10000/SUNW,pln@a0000000,802949/ssd@1,3 19
>ssd
>krz10 /sbus@2,0/SUNW,soc@d,10000/SUNW,pln@a0000000,802949/ssd@1,4 9
>ssd
>krz18 /sbus@2,0/SUNW,soc@d,10000/SUNW,pln@a0000000,802949/ssd@1,4 20
>ssd
>krz10 /sbus@2,0/SUNW,soc@d,10000/SUNW,pln@a0000000,802949/ssd@2,0 10
>ssd
>krz18 /sbus@2,0/SUNW,soc@d,10000/SUNW,pln@a0000000,802949/ssd@2,0 32
>ssd
>....
------------------ Answers -------------------------------
--- my comments
<mdb@dosmanos.cwiz.com (Martin D. Baldenegro) >:
Try the following things:
1. move the path_to_inst file to old.path_to_inst
2. creat new path_to_inst file with only the
following line in it:
#path_to_inst_bootstrap_1
3. remove the entries under /dev/vx
4. do this on both systems and boot with the -r option.
--- It sounds good, but I didn't try it.
------------------------------------------------------------
"Coffindaffer Virginia" <Virginia.Coffindaffer@wang.com>
Hinted me to HA-Software, so did Mark Spooner.
<mark.spooner@Central.Sun.COM>:
Qualix HA+ modifies the numbers as part of a HIghly Available NFS server
installation.
--- We don't like it now.
--- SDS supports disksets with one host being owner and the
--- second the backup. No more products, at this time.
------------------------------------------------------------
Seth Rothenberg <SROTHENB@montefiore.org>
reported, that he faced a similar problem. The dev-names differed
c2t4d4s4 c3t4d4s4. They moved this names and rebooted.
--- We had problems with the minor numbers.
------------------------------------------------------------
<rogerio@bvl.pt>:
We had a similar problem, with a 2000 and 3000.
Solution (it's working) from our frendly supplier :
Edit /etc/path_to_inst , so that there is only one
reference to each array, and the major and minor are the same
ex. these entrys :
"/io-unit@f,e0200000/sbi@0,0/SUNW,soc@1,0/SUNW,pln@a0000000,8424cf/ssd@
4,4" 79 " ssd"
"/io-unit@f,e0200000/sbi@0,0/SUNW,soc@1,0/SUNW,pln@b0000000,8424cf/ssd@
4,4" 174 "ssd"
"/io-unit@f,e1200000/sbi@0,0/SUNW,soc@3,0/SUNW,pln@b0000000,8424cf/ssd@
4,4" 39 " ssd"
where modified to
"/io-unit@f,e0200000/sbi@0,0/SUNW,soc@1,0/SUNW,pln@b0000000,8424cf/ssd@
4,4" 54 " ssd"
Yes we did have three (3) entrys for our older array...and it even did
have one with a diferent controller address and Fiber port.
So, even having two diferent CPU's, we do have disk set's configured
and working.
HTH, but not the time to answer before,
--- fine, I acted in a similar way. Yust didn't understand why f(79,174,39)=54.
--Boundary_(ID_IR7Bd5kFBDMagRUYkQ9i0Q)
Content-type: text/plain; name=RFC822.TXT; charset=US-ASCII
Content-disposition: attachment; filename=RFC822.TXT
Content-transfer-encoding: 7bit
Received: from relay.urz.uni-heidelberg.de by krzmail.krz.uni-heidelberg.de (ccMail Link to SMTP R6.01.01)
; Fri, 27 Feb 98 11:08:38 +0100
Return-Path: <sun-managers-relay@ra.mcs.anl.gov>
Received: from ra.mcs.anl.gov (ra.mcs.anl.gov [140.221.9.21])
by relay.urz.uni-heidelberg.de (8.8.8/8.8.8) with ESMTP id LAA09871
for <bfank@krzmail.krz.uni-heidelberg.de>; Fri, 27 Feb 1998 11:06:56 +0100 (MET)
Received: from localhost (daemon@localhost) by ra.mcs.anl.gov (8.8.3/8.8.3) with SMTP id DAA06981; Fri, 27 Feb 1998 03:21:01 -0600 (CST)
Received: by ra.mcs.anl.gov (bulk_mailer v1.5); Fri, 27 Feb 1998 03:20:58 -0600
Received: (from daemon@localhost) by ra.mcs.anl.gov (8.8.3/8.8.3) id CAA06868 for sun-managers-outbound; Fri, 27 Feb 1998 02:24:42 -0600 (CST)
Sender: sun-managers-relay@ra.mcs.anl.gov
Received: (from listserv@localhost) by ra.mcs.anl.gov (8.8.3/8.8.3) id CAA06861 for smmsgs-out; Fri, 27 Feb 1998 02:24:38 -0600 (CST)
Received: from relay.urz.uni-heidelberg.de (relay.urz.uni-heidelberg.de [129.206.119.201]) by ra.mcs.anl.gov (8.8.3/8.8.3) with ESMTP id CAA06854 for <sun-managers@ra.mcs.anl.gov>; Fri, 27 Feb 1998 02:24:27 -0600 (CST)
From: bernhard_fank@krzmail.krz.uni-heidelberg.de
Reply-to: bernhard_fank@krzmail.krz.uni-heidelberg.de
Followup-to: bernhard_fank@krzmail.krz.uni-heidelberg.de
Received: from krzmail.krz.uni-heidelberg.de (krzmail.krz.uni-heidelberg.de [129.206.90.10])
by relay.urz.uni-heidelberg.de (8.8.8/8.8.8) with SMTP id JAA04140
for <sun-managers@ra.mcs.anl.gov>; Fri, 27 Feb 1998 09:27:54 +0100 (MET)
Received: from ccMail by krzmail.krz.uni-heidelberg.de (ccMail Link to SMTP R6.01.01)
id AA888571731; Fri, 27 Feb 98 09:29:32 +0100
Message-Id: <9802278885.AA888571731@krzmail.krz.uni-heidelberg.de>
X-Mailer: ccMail Link to SMTP R6.01.01
Date: Fri, 27 Feb 98 09:26:08 +0100
To: <sun-managers@ra.mcs.anl.gov>
Subject: Different minor-numbers at 2 E3000 conected to SSA112
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk
--Boundary_(ID_IR7Bd5kFBDMagRUYkQ9i0Q)--