- 论坛徽章:
- 1
|
解锁即可
可参考hacmp的解锁脚本
还有参考如下:- VPATHs inaccessible after AIX upgrade or server replacement.
- Technote
-
- Problem
- VPATHs inaccessible after AIX upgrade or server replacement. Error log records VPATH_RESV_CFLICT errors. Please note that inaccessible vpaths can manifest numerous symptoms such as the inability to import or varyon a volume group.
-
- Cause
- VPATHs inaccessible after AIX upgrade or server replacement. Error log records VPATH_RESV_CFLICT errors. All four of these criteria must be satisified in order for this document to apply:
- 1) vpath devices are inaccessible (see note below) after AIX upgrade or server replacement.
- 2) A version of SDD for nonconcurrent HACMP was installed prior to the upgrade or replacement.
- 3) A version of SDD for nonconcurrent HACMP is installed after the upgrade or replacement.
- 4) errpt shows VPATH_RESV_CFLICT errors.
- If all four of the above criteria have been satisfied, the problem is most likely caused by a persistent reservation set by the previous level or instance of AIX. Persistent reserves are set by the attached host but managed by the ESS and persist beyond the reboot or reinstall of the attached host.
- When AIX does a shutdown, it commits all pending writes to disk but does not varyoffvg the volume group or close its underlying devices. Since the vpath device in an on-line volume group is not closed on a normal shutdown, the persistent reserve is not cleared. Usually this does not present any problems because the same reservation key (stored in the ODM) is used once the host is powered back up.
- However, in the event of an AIX upgrade or server replacement, the reservation key is regenerated and may not be same as the reservation key generated by the previous OS. If the persistent reserve set by the previous OS is still in force when the new OS attempts to open the vpath, VPATH_RESV_CFLICT errors will be logged in the system error log and open will fail. This occurs because the new OS reserve key cannot be used to open a LUN previously reserved with the old reserve key.
-
- Solution
- Verify that no other host has valid access to the affected LUNs. If the LUN is open or volume group is on-line on another host, DO NOT attempt to forcibly clear the reserves. Data corruption can occur.
- If no other host has access to the affected LUNs, forcibly clear the stuck persistent reserve by successively executing the following command on all affected vpaths:
- lquerypr -c -h /dev/vpath# (Where # is substituted with the vpath special file number)
- Then, verify resolution by executing the following on all affected vpaths:
- lquerypv -h /dev/vpath# (Where # is substituted with the vpath special file number)
- If the vpath is functioning properly, the lquerypv command will return a block of formatted hex. If the vpath is inaccessible for any reason (such as hardware or reservation issues), the lquerypv command will complete without returning anything. At this point, access to vpaths should be regained (i.e. lquerypv returned a blocks of formatted hex).
- This problem can be avoided by manually varying off all ESS volume groups prior to upgrading or reinstalling the OS or retiring/replacing the server.
复制代码 |
|