PV has been returned to vg

[Javier Ortiz Guajardo]

I receive this message
vmunix: LVM: PV 5 has been returned to vg[17].

how can i identify which VG is talking about?, i just have 12 vg in the system. What means the 17?

i don??t have any other message related with this problem.

Thanks.

[Massimo Bianchi · Accepted solution]

Hi,
what are the minor number of the vg ?

ll /dev/vg*/group


I think it is related to the minor number...

HTH,
Massimo

[Jean-Louis Phelix]

Hi,

I think that you should look for a vg whose group file would have minor 0x110000 (17 in hexa).

This only means that your PV couldn't be reached during a short period of time, but now reponds again correctly. Perhaps you had a brief heavy io transfer.

Regards.

[Massimo Bianchi]

Hi,
there should be also output from the dmesg, stating some other problem with disks.

Is there any such message?

Massimo

[James A. Donovan]

In this case, 17 is the decimal equivalent to the number represented by XX in the following command

# mknod /dev/vgYY/group c 64 0xXX0000

In your case, XX=11 (11 in hex = 17 decimal)
Check your /dev/vgYY directories to see which group node matches 0x110000

[James R. Ferguson]

Hi:

See Technical Knowledge Base document #RCLVMKBRC00000110.

Regards!

...JRF...

[Steven E. Protter]

A disk, PV 5 took longer than the default timeout to respond to the system request for "roll call" A disk has to let the system know its there once in a while.

I think the default is 60 seconds and the max is 180.

If it doesn't happen often, don't worry about it.

If it is accompanied by an lbolt in the dmesg output, replace the disk.

lbolts should not be ignored.

Timeouts can be ignored, and you can increase the timeout on disks that are especially busy.

If you have lbolts this can be caused by bad disk, bad cables, a bad drive cage, or a scsi card that is flakey or not terminated properly.

Check all that stuff and let us know if you see anything.

SEP

[Helen French]

The number normally comes from the "minor" number of the "group" device file. This message can be just a warning in some case, but can be a critical h/w failure too. Check the reported physical disk with disk tools (STM, dd etc) and see if it has any h/w problem. If not, you may consider changing the SCSI time out value:

# pvchange -t time_out_value /dev/dsk/device_file

I would check the syslog continously and then take proper actions.

[Javier Ortiz Guajardo]

There is not any lbolt message.

and how can i identify de PV 5 vgdisplay? /etc/lvmconf/vgXX.conf?

where.

[James R. Ferguson]

Hi (again):

The document I cited (RCLVMKBRC00000110) describes how to identify both the VG and the PV in question.

Regards!

...JRF...

[Enrico P.]

Hi,
probably your messagge is accompanied by a similar:

vmunix: LVM: Recovered Path (device 0x1f0c1400) to PV 0 in VG 1

ll /dev/dsk | grep 0c1400 (last six digit)

for pick out the disk' s special file.

pvchange for modify timeout

Enrico.

[Helen French]

Like JRF said, that TKB document has the instructions. If you don't have access to it, then this is what it is:
To find PV, check vgdisplay ???v /dev/vg02 and list all PVs, then:

echo 201c?D | adb /dev/dsk/cxtydz (repeat this for all PVs)
You will get an output like this ??? ???201C: 1???. The one that returns the correct number on the right column is the PV.

[Helen French]

Correction - replace /dev/vg02 with your VG number:

# vgdisplay -v /dev/vgXX

[Changchun Teng]

Hi JRF

I could not found the document accroding to the ID(#RCLVMKBRC00000110 or RCLVMKBRC00000110) you provided. How and where can I get it?

Regards
Scott