EMC VG mystery

[Roger Baptiste]

Alan,

This may or may not be
related to the problem, but
make sure there is
no clash in the minor numbers
of the LV on the problematic
VG.

-raj

[Carlos Fernandez Riera]

Someone( my Friend Engineer) had told me to rollback LVM command and cummulative patchs.

Last two are not exactly fine.

[Wodisch]

Hello,

have you tried to assign a new VGid to *all* the disks in that group *before* you do the "vgimport"?
Like

1) split mirror
2) use "vgchgid" at once on ALL the "/dev/rdsk/..." which you have split off
3) now try "vgchange -a y /dev/vg... /dev/dsk/..."

does it work that way?

HTH,
Wodisch

[nancy rippey]

This may or may not apply to your problem. I have been working an EMC problem for a couple of weeks that I just got working last nigth.
All of my EMC devices were not showing up during an IOSCAN but I hade a vg and lv on the files and they mounted okay. My lvmtab was also messed up complaining about the number of disk in the kernel versus the lvmtab.
I did a vgexport on all my volume groups, except vg00 then reimported them. I also applied patches
PHKL_24004 and dependent patch PHKL_24187. A previous version of PHKL_24004 had do to with devices not appearing on an ioscan if luns had been skipped when assigning LUNS and other EMC type issues. I installed the patches and all is well.

Maybe this will help

[Steven Hargus]

Your problem sounds remarkably like a similar problem we just had. We don't have PowerPath installed. Syslog started showing LVM POWERFAIL messages late Saturday night. On the following Monday, the performance was unbearably slow, to the point connections were timing out. We traced it down to one EMC disk in a volume group (the third in a group of six disks). We could use "dd" to read data from the disk, and EMC support said there was a VGID present on the disk. After rebooting the server, that volume group would activate, but it would take a while. However, any access to the volume group would hang. We tried to fail over to the adoptive node (this is a SG cluster) and got the same results. After many panic'ed hours HP support suggested doing a "vgcfgrestore" to the disk. This would not work on the PRIMARY path, but worked on the ALTERNATE path. Lo and behold, it fixed everything! We still don't know what happened, HP blames EMC and EMC blames HP. The question we have is, What triggered the LVM POWERFAILED messages? The disk was readable, and it had to have the correct VGID (because the volume group DID activate) but any access to the VG would hang.

[Alan Riggs]

LAtest word from HP is that an error in the latest LVM cumulative patch causes this problem when vgdfgrestore is used to rewrite the LVM header on *all* disks in a VG. Since this particular VG only has one disk--ouch.

Fix is to roll back to PHKL_22529 (PHKL_24268 on 11.00). I have tested the rollback in development and will run it on the production server this weekend. If ym VG activates afterwards, I will let folks know. If not, I will let folks know *after* I let HP know.