LVM and VxVM

Problems with mounting volume group

 
SOLVED
Go to solution
Joanne Keegan
Regular Advisor

Problems with mounting volume group

Hi Everyone,

Last week the PDC was updated on our L3000. The controller number for our EMC disks changed. We modified the scripts to match the new number and tried to mount the EMC BCVs. 7 out of 8 worked. With the one that didn't work, it created the directory /dev/vgsapdb1_bcv, but didn't create any of the logical volumes.

We have tried everything we can think of. Has anyone experienced anything similar? Any ideas? I do award points.

Cheers,

Jo
5 REPLIES 5
Robert-Jan Goossens
Honored Contributor

Re: Problems with mounting volume group

Hi Jo,

Could you check the output from

# ll /dev/*/group

Ceck for unique minor numbers.

Did you vgimport the other volume groups ?

Regards,
Robert-Jan
Robert Binkhorst
Trusted Contributor

Re: Problems with mounting volume group

Hi,

What I'd do in this instance is to check if the new disk device (c8t3d0) is seen by the OS and by EMC. Can you try the following:
- Run a powermt display dev=all and check for the number you think EMC uses for the disk.
- Run an ioscan -fnCdisk and see if you can find the same one.

Whilst running the ioscan, also check if there are any disks there that don't have a devicename assigned to them. If they exist you'll want to run a insf -a and create all the devices. (this is non-destructive). Then you'll probably need to change the scripts and add the new disk device number to them.

Good luck,

Robert
linux: the choice of a GNU generation
Joanne Keegan
Regular Advisor

Re: Problems with mounting volume group

Thanks for the replies so far...

All the volume groups are vgimported - though it works for 7 out of 8 of them vgs.

The mknod numbers are unique, and the EMC and OS device files are correct.

Cheers,

Jo
Michael Tully
Honored Contributor

Re: Problems with mounting volume group

Hi Jo,

Have you tried to run the script(s) manually? What messages are being given?

We do this type of thing (mounting BCV's) on a regular basis, but usually manually. What is the sequence of events?

Is it possible that you can try a fresh copy off your R1/R2?
vgchange off
vgexport
establish --> split
vgchgid
mkdir /dev/???
mknod /dev/???/group c 64 0x0?0000
vgimport in preview mode

Regards
Michael
Anyone for a Mutiny ?
Colin Topliss
Esteemed Contributor
Solution

Re: Problems with mounting volume group

Try to vgimport the volume group manually, just in case there is a problem with your script.

Get to the point where you have your 7 out of the 8 vgs mounted.

Use symmir -g to ensure that all of your BCV's have split successfully. A bad split will give you problems.

Manually create your mount point ready to import the volume group
mkdir /dev/vgsapdb1_bcv
mknod /dev/vgsapdb1_bcv c 64
vgimport /dev/vgsapdb1_bcv

If the import is fine (ie no errors) then you should find yourself with lvol and rlvol files in the /dev/vgsapdb1_bcv directory.

If not, post the output from symmir and the error you see when doing the manual import.

If it worked, and you had the default naming for your lvols, then you can continue by activating your volumegroup:

vgchange -a y /dev/vgsapdb1_bcv

then mount the filesystems where ever they need to be.

If you use specific names for the lvols, then you'll need to determine what each one is by mounting it somewhere and looking at the contents. Note them down, because you'll need to change the lvol names to what they should be. Personally I'd vgexport the volume group again using the -f and -m flags:

vgexport -f /tmp/pv_map -m /tmp/lv_map /dev/vgsapdb1_bcv

Edit the /tmp/lv_map and put in the new names as you noted previously.
Do you mkdir and mknod as detailed above.

vgiport -f /tmp/pv_map -m /tmp/lv_map /dev/vgsapdb1_bcv
vgchange -a y /dev/vgsapdb1_bcv
mount your filesystems.

Phew! If that all worked, but still fails when using your script, then I hate to say it but you have a bug in there somewhere.