vg disk device file changed

[Team Leader UNIX DBA]

After an HP-UX B.11.11 server was rebooted, one of the device files from Secure Path changed from c20t1d1 to c20t1d2 so one of the volume groups can no longer see the device. How do I reconfigure the volume group to use the new device file? The volume group had only one device and was not mirrored because the LUN is raid5.

[Devender Khatana]

Hi,

You need to reimport the VG with new device file.

First find out unique minor number for the new VG using
#ll /dev/*/group

Let us say the sequence goes like

0x010000
0x010000
0x020000
0x030000
0x040000
0x050000

Select next number as your number. Here say 0x060000

Now

#mkdir /dev/newvgname
#mknod /dev/newvgname/group c 64 0x060000
#vgimport /dev/newvgname /dev/dsk/c20t1d2

You will find all file system device files under /dev/newvgname after import.

Mount them on required mount-points and change entries in /etc/fstab to reflect new file system device files.

HTH,
Devender

[Adisuria Wangsadinata_1]

Hi,

You can use 'pvmove' command.
For more details, check the manpage of pvmove :

# man pvmove

Hope this information can help you.

Cheers,
AW

PS : it's a good backup also if you backup the LVM configuration with vgcfgbackup command.

[Luk Vandenbussche · Accepted solution]

Try this

mv /etc/lvmtab /tmp
vgscan
strings /etc/lvmtab (to check if all VG are there)
vgchange -a y vgxx
mount -a

[Denver Osborn]

Devender has a solution that should do it for you... however, you'll want to export the vg then import. You wouldn't use pvmove in this scenerio. Here are the steps to perform the export/import.


ll /dev/vgname/group
(take note of the minor#)

I assume the vg is not active at this time...

vgexport -v -s -m /tmp/vgname.map /dev/vgname
mkdir /dev/vgname
mknod /dev/vgname/group c 64 0x??0000
(where 0x??0000 matches the minor# fom ll above)
vgimport -v -s -m /tmp/vgname /dev/vgname
vgchange -a y /dev/vgname

This should do it if the only thing that changed was the device used for the PV.

Hope this helps,
-denver

[Pete Randall]

I'm with Luk on this one. The device file simply needs to be re-associated with it's VG. That's what vgscan is for - no need for imports or pvmoves or anything.


Pete

[Denver Osborn]

vgscan would work, but be aware that things from your current config could change (re: boot info and pv links). If you use vgscan to correct the pv device file change, then 1st run it w/ '-p -v' options to preview what will be done. To understand possible chnages you might have to make following the vgscan, check out the manual page just to give you a heads up so there won't be any surprises.

if this were a production box w/ a good number of volume groups, I'd probably opt for vgexport/vgimport to fix the one vg.

-denver

[Borislav Perkov]

Hi,

I have same problem.
I solve it this way:

Deactivate the vg.
vgexport -m /tmp/vgXY.map /dev/vgXY
mkdir /dev/vgXY
mknod /dev/vgXY/group c 0x0N0000 N is the vg number
vgimport -v /dev/vgXY /dev/dsk/c20t1d2 in your case.
Last command meens that you import the vg definitions from the disk c20t1d2 and you include that disk in the volume group.
You have to activate the vg at last.

Regards,
Borislav

[Team Leader UNIX DBA]

Thank you all very much for your responses. I chose to use vgscan which seemed to be a much more elegant way to fix it and it worked beautifully!

Keep up the good work.

Danny

[Team Leader UNIX DBA]

Closing the thread.