Adding unit in MSA70 via P800 with MSA$UTIL on OpenVMS fails

[Bo Midberg]

Dismounted the device at OS level, and deleted the raid unit in MSA$UTIL with 2 disks, then moved those disks to another server (also OpenVMS) to upgrade the firmware on those disks (a critical update),.

After the firmware upgrade, the 2 disks could be mounted and examined on the server where the firmware update were carried out, but when moving those disks back to the original server, and trying to recreate the RAID unit on that server, it fails:

MSA> add unit 0 /disks=(201,206) /raid_level=1
set_configuration SCSI status = ff, ASC = 0, ASCQ = 0

SCSI status was: Reserved..
Dump of CDB used:
27, Opcode 39 : BMIC write or no data transfer operation.
0, Logical Unit Number 0.
0, Command specific: 0.
0, Command specific: 0.
0, Command specific: 0.
0, Command specific: 0.
51, BMIC: Set Configuration.
2 0, Bytes to transfer = 512.
0, Reserved, must be 0.
Adding or modification of Raid Unit failed.
MSA>

First, thought that it was due to that the corresponding device existed in the OS level since earlier, and alas made a cluster reboot, but the error is still the same, and I cannot find any information about how to reset the disks or unit, neither about the full meaning of the provided information.

MSA> show unit 0
Logical Unit does not exist.
MSA>

So, from the raid controller the unit does not exist, and that is also the case at OS level, and the disk information do not give much:

MSA> show disk 201/full

SAS device [Disk]
Disk 201: bus: 1, Target id: 8, Port: 1E, Box/Enclosure: 2, Bay: 1, size 279.
40 [300.00]GB
Disk 201, # 0, size 585871964 blocks, (279.37 [299.97] GB), Unused.
Connector Location External
Connector 1E.
Enclosure 2.
Bay 1
WWID 0x5000c5004bb36115
Device Type Disk
Device Vendor ID HP
Device Product ID EH0300FBQDD
Device Serial Number 6XN0KKNR0000M235HB7N
Device Firmware Version HPD3
Reserved blocks 65536. (32.000000 MB)
Block Size(bytes/sector) 512.
RPM 15015.
Compaq Drive Stamp(M&P Data Stamp) Yes
Last Failure Reason Removed in hot plug.
Physical Disk Flags:
S.M.A.R.T. predictive failure supported Yes.
S.M.A.R.T. predictive failures recorded in the factory M&P data No.
S.M.A.R.T. predictive failure is enabled Yes.
S.M.A.R.T. predictive failures recorded in the since power M&P data No.
Drive attached to external connector
Yes.
write cache is changeable and drive has a "safe" write cache.
MSA> show disk 206/full

SAS device [Disk]
Disk 206: bus: 1, Target id: 13, Port: 1E, Box/Enclosure: 2, Bay: 6, size 279
.40 [300.00]GB
Disk 206, # 0, size 585871964 blocks, (279.37 [299.97] GB), Unused.
Connector Location External
Connector 1E.
Enclosure 2.
Bay 6
WWID 0x5000c5004b96f975
Device Type Disk
Device Vendor ID HP
Device Product ID EH0300FBQDD
Device Serial Number 6XN0JRYN0000M2322TW3
Device Firmware Version HPD3
Reserved blocks 65536. (32.000000 MB)
Block Size(bytes/sector) 512.
RPM 15015.
Compaq Drive Stamp(M&P Data Stamp) Yes
Last Failure Reason Removed in hot plug.
Physical Disk Flags:
S.M.A.R.T. predictive failure supported Yes.
S.M.A.R.T. predictive failures recorded in the factory M&P data No.
S.M.A.R.T. predictive failure is enabled Yes.
S.M.A.R.T. predictive failures recorded in the since power M&P data No.
Drive attached to external connector
Yes.
write cache is changeable and drive has a "safe" write cache.
MSA>

The RAID controller firmware, which is the last available for download:

MSA> show version
MSA_UTIL V4.00
Build 12-Jan-2012

Adapter: _PKE0: (DEFAULT)
Firmware version: 7.22
MSA>

All other disks we have of this type (EH0300FBQDD), have all the firmware version HPD3, so it cannot be a firmware conflict on the particular raid controller.

[Steven Schweda]

   I know almost exactly nothing about this stuff, but wouldn't it make
more (that is, some) sense to post this question in a VMS forum (which
this "General Feedback and Suggestions" forum is not)?

      http://community.hpe.com/t5/OpenVMS/ct-p/itrc-288

   Perhaps you can persuade a moderator to move it.

[Hoff]

Call HPE support.   This is deep in one of the various "call HPE support" parts of OpenVMS, and where there's comparatively little documentation available.  If you want to avoid (delay making?) that call, patch OpenVMS to current, and haul the disks over to a "not-smart" SCSI controller and see if they work there, and also try to erase the disks over there.

[Bo Midberg]

Moved drives to another OpenVMS Integrity server, but with a P812 controller and a D2700 disk cabinett. On this server there are no problems to create (add) the unit as a mirror of the disks, and then manipulate it in OS, like initialize the "disk".

Then deleted that unit in MSA$UTIL, and move it back to the original server with P800 and MSA70. Still the same problem. Then tried to use other slots in MSA70 and another unit number in P800, but the result was the same.

Then moving the drives back to the server with P812+D2700. There is no problem in recreating a unit with those disks in that configuration.

Both servers are up to date with OpenVMS patches, so that cannot be an explanation.

Alas, there are some problem with P800 and/or MSA70. The current FW on P800 is 7.22. There is a 7.24 version available, but seems not to have any fix for this situation. Cannot see that the logs are filled as described in release notes for 7.24. The FW on MSA70 is 2.18 as this seems to be the recommended FW for this controller (P800), while 2.28 only applies to certain controllers.

Also tried to find any offline tool for P800 (like ACU) and Integrity, but could not find any.

[Bo Midberg · Accepted solution]

Could add unit in P800 BIOS with these disks with system shut down. After bringing VMS up there is no problem to mount and manipulate this unit. The theory is that the internal caibet and D2700 are single port while MSA70 is dual port, and that using a disk in a single port cabinett may make MSA$UTIL unhappy when trying to create a unit with those disks in a dual port cabinet like MSA70.