Sun System Handbook - ISO 3.4 June 2011 Internal/Partner Edition | |||
|
|
Solution Type Problem Resolution Sure Solution 1003564.1 : Sun StorEdge[TM] T3 / T3+ / 6320 Arrays: How to Clear Persistent Group Reservation (PGR)
PreviouslyPublishedAs 205019
Applies to:Sun Storage 6320 SystemSun Storage T3 Array All Platforms SymptomsPersistent Group Reservation (PGR) left on volumes.CauseIn some circumstances, the Sun[TM] Cluster software can leave a Persistent Group Reservation (PGR) that is set on these arrays: Sun StorEdge[TM] T3, Sun StorEdge[TM] T3+, and Sun StorEdge[TM] 6320. The normal process for clearing this PGR might not work.SolutionUse the Sun Cluster software commands that are outlined in <Document 1011961.1> Solaris Cluster: Removing SCSI Reservations.This approach is not specific to the Sun StorEdge T3, Sun StorEdge T3+, and Sun StorEdge 6320 arrays, but it should work.
If you are unable to clear the PGR by using /usr/cluster/lib/sc/scsi or if the PGR was set by a product other than Sun Cluster software, then contact the Oracle support and reference this document. Warning: the use of commands that start with "." is not officially supported but there are some functions that are occasionally required (as is the case here). Ultimately, these functions will be migrated to the supported command set, but currently, the customer can be left with no other option but to use "." commands. In addition, for Sun StorEdge T3+/6X20 arrays with Controller Firmware 3.x, the "." commands are password protected. You need to issue the command "sun" and give the password "arrayservice" before you can use commands that start with ".". In this case, you need to engage a local Sun resource to perform the operation because this information cannot be given to the customer. Internal Workaround 1: Use the cleargrp Command
In a Storage Area Network (SAN) situation, the fabric numbers of the logical unit numbers (LUNs) might have changed. If you encounter this problem, you can resolve it by using "cfgadm -c configure X," where X is the controller number that is connected to the SAN which contains the affected array (there might be more than one controller). You need to do this for every server that accesses the affected array. You need to do a final reboot to confirm that devices can be accessed normally. Attachments This solution has no attachment |
||||||||||||
|