etc/lvmtab is out of date with the running of kernel

[jaminas]

My system version is HP K450 OS is 10.20X.
A volume group housing physical volumes /dev/dsk/c3t3d0 and /dev/dsk/c1t3d0 contain databases files and log files. I realized that the database was down and in an attempt to re-start it, I realized that one of the PV is not accessible (i.e /dev/dsk/c1t3d0).

Can I use pvchange to siwtch to the other disk or what do I do?

Thanks in advance

[RAC_1]

Was it a alternate disk for failed disk? If yes, you should have switched to alternate link by default. Are those disks accessible and can be seen on system? Unless they are there and accessible by system, you can not do anything.

[uadm26]

Hi,
You need know if the system detect that disk.
ioscan -fnC disk

If the system list the disk you need to test him:
It's better if have a console near the server.
dd if=/dev/dsk/cxtydz of=/dev/null
(disk with problem)

If it's work the light must blink.
If nothing happend you can halt the system remove and put back the disk and boot the system again.

Joel

[Luk Vandenbussche]

Try the following is /etc/lvmtab is out of date

mv /etc/lvmtab /tmp
vgscan

vgdisplay -v

[Andrew Jendricks]

Hi Nasir,

I'm not sure exactly your question. Did you receive an error stating that lvmtab is out of date with running kernel? Because having one drive fail shouldn't cause that to happen. A drive failure may however cause other problems.

Assuming the problem is that the drive is missing, you can do the following:

Providing the lvols in that vg are mirrored onto the two drives, then you can activate the vg in low quorum mode (or lack of quorum mode) with:

# vgchange -a y -l q /dev/vgXX

If the lvmtab is out of date with kernel, you can fix it by running vgscan as previously suggested, although that can cause other problems, especially if also have a failed drive at the time of the vgscan.

LVM likes checks and balances, and likes the vg information to match in each place that it's kept. It is kept on the drives, in the VGRA (actually two copies of this on each drive), also in /etc/lvmtab, and also in the kernel.

vgscan will only modify the info in the lvmtab and the kernel, but not the info in the vgra. So, if you were to vgscan to rebuild lvmtab, and if at the time of the vgscan one of the member drives in the vg was failed, it would build the lvmtab incorrectly, with only one disk. Likewise, it would update the lvm info in the kernel with only one disk. However the vgra, commonly refereed to as the the drive header info, would still know about that second disk. Then you would get a mismatch between active and current disks in a vgdisplay.

My suggestion would be to activate the vg with the "vgchange -l q" option, then reduce out the failed disk drive using vgreduce -f. That will correctly update lvmtab, kernel and vgra. Then, you can replace the failed drive, re-vgextend it back in, and re-mirror your lvols.

Hope that helps.

Andrew Jendricks
HP Critical Services Support