Syslog: There is a problem with LVM config

[Coolmar]

I have the following in the syslog:

date server:There is a problem with the LVM configuration.

It keeps repeating over and over.

vgdisplay -v /dev/vg01
--- Volume groups ---
VG Name /dev/vg01
VG Write Access read/write
VG Status available
Max LV 255
Cur LV 2
Open LV 2
Max PV 16
Cur PV 4
Act PV 4
Max PE per PV 8192
VGDA 8
PE Size (Mbytes) 4
Total PE 14622
Alloc PE 6944
Free PE 7678
Total PVG 0
Total Spare PVs 0
Total Spare PVs in use 0

--- Logical volumes ---
LV Name /dev/vg01/lvol1
LV Status available/syncd
LV Size (Mbytes) 13888
Current LE 3472
Allocated PE 3472
Used PV 1

LV Name /dev/vg01/lvol2
LV Status available/syncd
LV Size (Mbytes) 13888
Current LE 3472
Allocated PE 3472
Used PV 1


--- Physical volumes ---
PV Name /dev/dsk/c6t12d6
PV Name /dev/dsk/c4t12d6 Alternate Link
PV Status available
Total PE 3472
Free PE 3472
Autoswitch On

PV Name /dev/dsk/c6t12d5
PV Name /dev/dsk/c4t12d5 Alternate Link
PV Status available
Total PE 3472
Free PE 3472
Autoswitch On

PV Name /dev/dsk/c38t0d0
PV Name /dev/dsk/c35t0d0 Alternate Link
PV Status available
Total PE 3839
Free PE 367
Autoswitch On

PV Name /dev/dsk/c38t0d1
PV Name /dev/dsk/c35t0d1 Alternate Link
PV Status available
Total PE 3839
Free PE 367
Autoswitch On

LVINFO:
--- Logical volumes ---
LV Name /dev/vg01/lvol1
VG Name /dev/vg01
LV Permission read/write
LV Status available/syncd
Mirror copies 0
Consistency Recovery MWC
Schedule parallel
LV Size (Mbytes) 13888
Current LE 3472
Allocated PE 3472
Stripes 0
Stripe Size (Kbytes) 0
Bad block on
Allocation strict
IO Timeout (Seconds) default

--- Distribution of logical volume ---
PV Name LE on PV PE on PV
/dev/dsk/c38t0d0 3472 3472

--- Logical volumes ---
LV Name /dev/vg01/lvol2
VG Name /dev/vg01
LV Permission read/write
LV Status available/syncd
Mirror copies 0
Consistency Recovery MWC
Schedule parallel
LV Size (Mbytes) 13888
Current LE 3472
Allocated PE 3472
Stripes 0
Stripe Size (Kbytes) 0
Bad block on
Allocation strict
IO Timeout (Seconds) default

--- Distribution of logical volume ---
PV Name LE on PV PE on PV
/dev/dsk/c38t0d1 3472 3472


History: We are connected to a Hitachi SAN and everything is fine. However, we are moving our data off the Hitachi and onto an IBM8300 Shark. I was assigned a couple of LUNs that are configured "open system DS size" according to the SAN people. Anyway, we see the LUNS, I am able to add them to the volume group and mirror the data without issue. The problem is upon reboot, vg01 becomes deacivated and I have to activate it manually after the server is up and running.

Any ideas?

[James R. Ferguson]

Hi Sally:

If you reboot and your volume group requires manual activiation ('vgchange -a y') look at 'etc/lvmrc'. This sounds like you have customized activation instead of :

AUTO_VG_ACTIVATE=1

Regards!

...JRF...

[Coolmar]

It is already set to auto_activate. The problem is that it bombs out when it tries to mount vg01 on bootup...before the startup/rc scripts even start to load. The syslog is full of the error above.

[Victor BERRIDGE]

Hi Sally,
I dont see the mirrot in your output, should I understand ...after "we split" and are now on IBM exclusively?
In which case you may still have the disks definition in lvmconf and it is looking for them and cant find them because have been removed


Just thoughts

Good luck
Victor

P.S.
May I ask the reason for leaving HDS for IBM shark?

[Coolmar]

Good idea Victor, but I did reboot already while they were still mirrored and got the same problem. I am in the process of breaking the mirror and going Hitachi only. Reboot. Mirror the shark in again, then reboot. Then IBM only, and reboot again. See what happens. HOpefully it was just corrupt lv or something.

[Kirby A. Joss]

We've had HP systems on 3+ Storage * n SAN configurations and seen variants of boot time startup issues with almost everything except EMC with pvlinks. IBM's SDD seems too slow firing up for AUTO_VG_ACTIVATE. We have backed it out (hd2vp) in an attempt to fix mediate a race condition on the boot time auto-mounted VGs.

We saw an assortment of problems depending on where in the SDD startup the VG activation hit, but most commonly, missing PVs (which were there by the time we could log in to look). The VGs under MCSG seem to be there in time for cluster startup.

[freddy_21]

maybe you must check about FC conection. I had some problem like that. Some time your IBM disk not ready when the server boot. so when the server boot, server not accept conection to the disk. so it will be skip for activating volume group. please check your server when rebooting.

If u have same problem like me, you must increase IO Timeout at your server. i saw your i/o time out 30 sec ( default )

use pvchange command

Good luck
freddy