PVLink 31 0x160600 Failed!

[Ivan-Maximov]

I have rx1620 and link to it disks from EVA5000.

And I have error messages in my syslog like this:

May 10 10:40:27 rx1620 vmunix: LVM: Performed a switch for Lun ID = 0 (pv = 0xe00000016441c000), from raw device 0x1f140600 (with priority: 2, and current flags: 0x40) to raw device 0x1f040600 (with priority: 0, and current flags: 0x80).
May 10 10:40:27 rx1620 vmunix: LVM: VG 64 0x060000: PVLink 31 0x040600 Recovered.
May 10 10:40:27 rx1620 vmunix: LVM: VG 64 0x060000: PVLink 31 0x140600 Failed! The PV is still accessible.
May 10 10:40:27 rx1620 vmunix: LVM: VG 64 0x060000: PVLink 31 0x160600 Failed! The PV is still accessible.
May 10 10:40:48 rx1620 vmunix: LVM: VG 64 0x060000: PVLink 31 0x160600 Recovered.
May 10 10:40:55 rx1620 vmunix: LVM: VG 64 0x060000: PVLink 31 0x140600 Recovered.

What is couse of this message? How can I resolve this?

[Duncan Edmonstone]

What version of VCS is the EVA on?

IIRC PVLinks aren't supported with version 3.x. This only became available when the EVA went to active/active with VCS 4.x

HTH

DUncan

[Senthil Kumar .A_1]

Hi,

Actually the answer is "It depends".

Since the "Recovered" message is displayed at the end, I think you do not have to remediate anything at all. May be the server could have lost connection to EVA array momemtarily and recovered.

To validate it, you can run a command..

vgdisplay -v

Try noticing if there are any drive path that is indicated with the status "Unavailable". If you do not find any such line in the output, you can ignore the error message and ask the SAN team to check if there were any SAN switch related changes or array problems at "May 10 10:40:27". If you find any "Unavailable" status, then you might have to check with the SAN team to check the SAN fabric or EVA array itself.

SK

[Wim Rombauts]

These messages tell you that your system has :
1) Lost some physical connections to some physical volumes (LUN's), but that other connections are still available so that the physical volume can still be used.
2) Lost the primary connection to some physical volumes, and therefor switched to an alternate path
3) Regained the connections it previously lost.

So at the end, everything is ok. But you may want to investigate what caused the connection loss, because you may have a bad connection or so (loose or bad cable).

[Ashish Parashar]

Hello Ivan

You can try below option:-
[nlhenmd1:/]# echo "0x06=D" | adb
31
[nlhenmd1:/]#

[nlhenmd1:/]# lsdev -b 31
Character Block Driver Class
188 31 sdisk disk
[nlhenmd1:/]#

[nlhenmd1:/]# ll /dev/dsk | grep 06000
brw-r----- 1 bin sys 31 0x06000 Oct 23 2000 cXtXdX (you will get the affected lun)
[nlhenmd1:/]#

[nlhenmd1:/]# strings /etc/lvmtab | grep cXtXdX (check whether its in used or not)
/dev/dsk/c8t11d0
[nlhenmd1:/]#


if used then execute pvdisplay /dev/dsk/cXtXdX (Check for stale and availability of lun)

Execute diskinfo XXXXX.

if find some thing wrong, i.e. need to replace that lun.

Cheers
Ashish

[Maxim Yakimenko]

Privet,

Pochinil?

[mavrick]

Use this comand to find out which disk having alerts

ll /dev/dsk/* | grep 160600
ll /dev/dsk/* | grep 140600
these commands output will give you the disk
device file
then check the
ioscan -fnC disk and see this disk is CLAIMED

if yes

diskinfo /dev/rdsk/
if it displays the full size of disk

then try the dd command to find any error in the block device

dd if=/dev/dsk/cxtxdx of=/dev/null bs=1024

if the output of this command shows no error.