OS Gyrations after a SAS disk is replaced on 11.31/rx6600 (sasmgr?)

[Alzhy]

Anyone replaced a SAS disk on an rx600 yet running 11.31? What gyrations do we need to do so we get an agile or legacy device back?

Thanks!

[Steven E. Protter]

Shalom,

Depends on the configuration.

If you set up hardware raid on the system and installed the OS on a raid 1 mirror set, there will be no problems at all replacing one of the OS disks.

If you did not do this, then you need to run an Ignite make_tape_recovery or make_net_recovery backup, because you will lose the OS without such a backup, which is a good precaution.

Like many issues in IT, the answer is, "it depends"

SEP

[Torsten.]

If the disk is part of a RAID, it is just plug and play.

If the "plain" disk is used, it gets a new device file while installing.

To configure it, see the steps here:

http://docs.hp.com/en/5992-3385/ch04s08.html#v1446838

[Alzhy]

Merci Boco Torsten,

Here's my issue:

We did not know one of our SAS disks (not part of a RAID volume on the sasd controller) failed.

When the OS came up, there was no device (agile or legacy). Going back through the logs there was indeed a failure way back which we did not caughtas we thought our 11.31 BaseOE did not come with EMS (well it appears it did).

So HP replaced the drive. "sasmgr" confirms the drive is there. And at this point we're confused what to do next.... Google sez - scsimgr replace_target and io_redirect_dsf should do the trick. I have so far done the former (as we do not use agile name for said SAS disk) - but no dice. Further reading shows these 2 commands only work if the device shows as NO_HW - which of course we're not at.

Help us Torsten, you're our only hope ;^).

(We're still waiting for our support ticket's response. We're relatively new with 11.31 and our mixed SAN Array ecosystem does not seem to help a lot... we're having various problems with 11.31 with respect to disk presentations and de-presentations but that is a different matter).

Merci Boco.

[Torsten.]

The new disk should have a device file anyway, unless the controller was configured to have a RAID in that slot.

I assume you have the default built-in SAS controller, not a smartarray - can you confirm?

So you should to a

# sasmgr get_info -D /dev/sasd0 -q raid

and post. Let us see what the controller can see.

[Alzhy]

Thanks Torsten, here it is. It's sad because the various docus I've seen (even the LVM docu) does not mention a case where the Server was rebooted with a Failed SAS disk and how it's replacement is handled. The disk is not a Boot disk as I used a RAID LUN from which I've build from the first 3 slots hanging off sasd0.

root@goofy # sasmgr get_info -D /dev/sasd0 -q raid

Wed Jan 14 06:59:46 2009

---------- PHYSICAL DRIVES ----------
LUN dsf SAS Address Enclosure Bay Size(MB)

/dev/rdsk/c75t0d0 0x500000e01cc0c4a2 1 4 140014
/dev/rdsk/c75t1d0 0x500000e01cbe7da2 1 5 140014
/dev/rdsk/c75t3d0 0x500000e01cbe89f2 1 7 140014
/dev/rdsk/c75t4d0 0x500000e01cbf9912 1 8 140014

---------- LOGICAL DRIVE 1 ----------

Raid Level : RAID 1
Volume sas address : 0x7ae51f966b5ed41
Device Special File : /dev/rdsk/c75t5d0
Raid State : OPTIMAL
Raid Status Flag : ENABLED
Raid Size : 139236
Rebuild Rate : 0.00 %
Rebuild Progress : 100.00 %

Participating Physical Drive(s) :

SAS Address Enc Bay Size(MB) Type State

0x500000e01cc0add2 1 2 140014 SECONDARY ONLINE
0x500000e01cbdce32 1 1 140014 PRIMARY ONLINE


---------- GLOBAL SPARE DRIVES ----------
SAS Address Enc Bay Size(MB) Pool State

0x500000e01cc0b842 1 3 140014 0 ACTIVE

[Alzhy]

BTW the disk is on Slot 6 (if its not obvious)... /dev/rdisk/disk17 -- and you're right -- we still have the device file (agile and legacy).

[Torsten.]

OK,

you have disks in slots

1+2 =RAID
3 = hot spare

4,5,7,8 = independent disks

Problem is with disk in slot 6?

Please run

# sasmgr get_info -D /dev/sasd0 -q phy=all

[Torsten.]

And BTW, is the any LED on on this disk?

I would expect a green light if the disk is not dead.

[Alzhy]

Apperciate it a lot Torsten:

root@goofy2 # sasmgr get_info -D /dev/sasd0 -q phy=all

Wed Jan 14 07:44:28 2009

Info for PHY ID : 0
PHY Health : UP
Port SAS Address : 0x500605b0009e9080
Attached SAS Address : 0x500000e01cc0c4a2
Current Link Rate : 3 Gbps
Max Link Rate : 3 Gbps

Info for PHY ID : 1
PHY Health : UP
Port SAS Address : 0x500605b0009e9081
Attached SAS Address : 0x500000e01cc0b842
Current Link Rate : 3 Gbps
Max Link Rate : 3 Gbps

Info for PHY ID : 2
PHY Health : UP
Port SAS Address : 0x500605b0009e9082
Attached SAS Address : 0x500000e01cc0add2
Current Link Rate : 3 Gbps
Max Link Rate : 3 Gbps

Info for PHY ID : 3
PHY Health : UP
Port SAS Address : 0x500605b0009e9083
Attached SAS Address : 0x500000e01cbdce32
Current Link Rate : 3 Gbps
Max Link Rate : 3 Gbps

Info for PHY ID : 4
PHY Health : UP
Port SAS Address : 0x500605b0009e9084
Attached SAS Address : 0x500000e01cbf9912
Current Link Rate : 3 Gbps
Max Link Rate : 3 Gbps

Info for PHY ID : 5
PHY Health : UP
Port SAS Address : 0x500605b0009e9085
Attached SAS Address : 0x500000e01cbe89f2
Current Link Rate : 3 Gbps
Max Link Rate : 3 Gbps

Info for PHY ID : 6
PHY Health : UP
Port SAS Address : 0x500605b0009e9086
Attached SAS Address : 0x500000e01cb7da02
Current Link Rate : 3 Gbps
Max Link Rate : 3 Gbps

Info for PHY ID : 7
PHY Health : UP
Port SAS Address : 0x500605b0009e9087
Attached SAS Address : 0x500000e01cbe7da2
Current Link Rate : 3 Gbps
Max Link Rate : 3 Gbps

[Torsten.]

Hmm, an empty slot would look like this:

Info for PHY ID : 0
PHY Health : DOWN
Port SAS Address : 0x0
Attached SAS Address : 0x0
Current Link Rate : 1.5 Gbps
Max Link Rate : 1.5 Gbps


So all disks are connected. Strange.

Let's check something else:

# sasmgr get_info -D /dev/sasd0

[Torsten.]

Disk in question is this:

Info for PHY ID : 6
PHY Health : UP
Port SAS Address : 0x500605b0009e9086
Attached SAS Address : 0x500000e01cb7da02
Current Link Rate : 3 Gbps
Max Link Rate : 3 Gbps

Maybe we should reset and/or re-seat this disk.

[Alzhy]

No LED faults Torsten.

But as far as OS gyrations.. after the drive as "replaced" what should be properly done? Those 2 commands does not seem to apply per HP's docs - since we're not NO_HW.

[Alzhy]

Torsten,

It turns out the ISSUE was the drive was not actually replaced (yet) all this time I was made to believe it was!

It was just replaced and the OS automagically allocated a "NEW" agile and legacy dsf.

I was able to have the former agile dsf be used via:

io_redirect_dsf -d /dev/disk/disk17 -n /dev/disk/disk6331

But I could not get it to have it bound to its old legacy dsf - which is c72t2d0 (via sasmgr replace_tgt:

disk 12 0/4/1/0.0.0.0.0 sdisk CLAIMED DEVICE HP DG146BABCF
/dev/dsk/c75t0d0 /dev/rdsk/c75t0d0
disk 5 0/4/1/0.0.0.1.0 sdisk CLAIMED DEVICE HP DG146BABCF
/dev/dsk/c75t1d0 /dev/rdsk/c75t1d0
disk 6 0/4/1/0.0.0.3.0 sdisk CLAIMED DEVICE HP DG146BABCF
/dev/dsk/c75t3d0 /dev/rdsk/c75t3d0
disk 4 0/4/1/0.0.0.4.0 sdisk CLAIMED DEVICE HP DG146BABCF
/dev/dsk/c75t4d0 /dev/rdsk/c75t4d0
disk 1 0/4/1/0.0.0.5.0 sdisk CLAIMED DEVICE HP IR Volume
/dev/dsk/c75t5d0 /dev/dsk/c75t5d0s2 /dev/rdsk/c75t5d0 /dev/rdsk/c75t5d0s2
/dev/dsk/c75t5d0s1 /dev/dsk/c75t5d0s3 /dev/rdsk/c75t5d0s1 /dev/rdsk/c75t5d0s3
disk 6330 0/4/1/0.0.0.6.0 sdisk CLAIMED DEVICE HP DG146BABCF
/dev/dsk/c75t6d0 /dev/rdsk/c75t6d0


The "new" legacy dsf is c75t6d0. I had wanted it bound to c75t2d0 using the syntax below but it is complaining:

root@goofy # sasmgr replace_tgt -D /dev/sasd0 -q old_tgt=/dev/dsk/c75t2d0 -q new_tgt_hwpath=0/4/1/0.0.0.6.0
ERROR: Invalid qualifier (old_tgt) was specified
sasmgr [-f][-h] replace_tgt -D -q old_dev=
-q new_tgt_hwpath=


So I guess it is NOT now possible to have this disk bound to its former/orignal legacy dsf? It really does not matter now at this time since I can use that new legacy dsf. Just want to find out IF it is possible.

So I was on the right track via the docus after all! But many many thnkas to you nevertheless good sir.

[VK2COT · Accepted solution]

Hello,

You made a slight typing error:

root@goofy # sasmgr replace_tgt -D /dev/sasd0 -q old_tgt=/dev/dsk/c75t2d0 -q new_tgt_hwpath=0/4/1/0.0.0.6.0

The correct syntax is:

root@goofy # sasmgr replace_tgt -D /dev/sasd0 -q old_dev=/dev/dsk/c75t2d0 -q new_tgt_hwpath=0/4/1/0.0.0.6.0

There is no command-line argument "old_tgt"
for sasmgr :)

Cheers,

VK2COT