vgchgid fails

[vinodan]

Dear All
Our's is a production environment.
We are doing business copy from production server to differenet server which is kept for report generation.server is attached to xp1024.Vg which containing P-Vols was having 88 ldevs previously.
problems started when when the number of ldevs allocated for the vg increased to
136(Now vg conatins 136 PVs).
After pairsplit while doing vgchgid system gives core dump.Since vgchgid fails successive vg activation also fails.
We are doing vg import to the server which is kept for report generation.Can anybody tell me why coredump happens while doing vgchgid ?

Regards
Vinod

[Steven E. Protter]

I would first check the patch situation.

Do you have a recent quartery update installed?

If so go to the itrc.hp.com main page, click patch/firmware database.

get vgchid patches in the search, select.
get lvm patches in the search, select.

Download all dependencies.

If its a big patch set, choose the ftp script option to get the patches, it is most reliable for big transfers.

SEP

[Robert Bennett_3]

We do not have the same environment as you, but we had a failure at vgchgid last night as well.

Ours is an EVA connected to a Director switch. I moved a couple of hba's to a new fabric yesterday and then our split failed last night at vgchgid. Ended up that the move changed the paths and therefore the device addresses to the disks being split. insf -e solved our problem. This may or may not be related to your problem, but vgchgid fails if it does not recognize the devices.

Hope this helps

B

[Devender Khatana]

Hi,

A better approach will be to check wheather all previous LDEV's have remains unchanged. Did you created new VG's or extended existing VG's on new LUNs? The problem is with new LUN's or even with old one's as well.

HTH,
Devender

[Matthew Ghofrani]

The fact that all disks in a vg need to be vgchgided at the same time in the same line could be the reason of failure. Possibly your execute line is running out of room for having that many ldevs. If that turns out to be the case, use meta disks (stripe disks behind the seen).

Take care from Matthew in Boston

[Alzhy]

Can you send us the script that does the pairsplit and then the vgchgid on your other server? While it is possible you have exceeded your shell's maximum command line un your vgchgid dirctive, it is also possible your vgchgid line is missing the newly added PV's.

What I usually do for such scripts (EVA BC or XP BC) is I get the VGID of the source VG on Server A. Once the split LUNS are presented on Server B, I go over all disks on that server using:

VGID=`echo 0x2010?2X|adb /dev/dsk/${PV}|expand|tr -d " "|sed "s/2010://"`

and search for VGIDs matching Server A's orginal VGID. I then create a list of PV's comprising this VG and use that as argument to my vgchgid and vgimport.

Another option - since your presenting your BC set to a different server is to simply leave the VGID unchanged. Simply import the VG on ServerB with the mapfile (with shared option so it has a VGID) from Server A. To generate a mapfile on Server A that you can use on Server B, do this:

vgexport -s -p -m /somepath/vgora.map /dev/vgora

[vinodan]

Dear All,
Thanks for all of your valuable suggestions.My problem got solved .Problem was with the script which we were using to
collect physical disk list for changing
vgchgid.It was collecting primary link as well as alternative links.So totally 272.
Maximum PV allowed in a vg is restricted to 255.We modified the script in such a way that it will take only primary link while collecting device file list for doing vgchgid.Thanks for our HP site engineer for solving this issue and same to all of you for giving a lot of valuable suggestions.

Cheers
Vinod