LVM2 devfs mappings changed for physical volumes...LV "went away"
 

I have an LVM2 volume that was created on a RHEL system. The physical volumes are from a storage array. Changes at the storage array level have caused the devfs mappings to change (e.g. /dev/sdb1 --> /dev/sdd1). This caused the LV that was created using the pv /dev/sdb1 to "go away". I'm nervous enough about loosing any data, so my question is; can I simply vgcreate using the new devfs mappings (which are still Linux LVM volumes as returned by fdisk -l) and then lvcreate a new logical volume without loosing data? Or better yet, is there a way for me to go into an LVM config file and change the old mappings to the new ones and reboot?

Thanks for any help in advance.

Unless you've got some filters set in your /etc/lvm/lvm.conf file to restrict which devices get scanned, LVM shouldn't care which device it finds the PV on. vgscan will scan all the available devices looking for LVM headers to identify the PVs. If you've got a PV missing, then doing a vgcreate is completely the wrong thing to do. You need to determin where your PV has gone and why its not being detected. I hope that whatever the change was you made to your storage array, that it was a non-destructive one.

You need to do a little digging with the lvm display commands to try and figure out exactly what's happened. 'vgs' and 'pvs' are a good place to start.

Thanks for the reply.

vgscan seemed to be all that was needed to discover the LV. I should have RTFM a bit more before jumping the gun on the post :). Man page on vgscan states that it will happen automatically, but you might still need to run it explicitly after a change in hardware.

The only change that was made at the storage array was the creation of new LUNs, assigned down the same controller (thus changing the SCSI channel discovery of the LUNs leading to the different devfs mappings).

Thanks for the help.

You're welcome. At least it's not like AIX where the old hdisk device entries go into a 'Defined' state when their id's change and you end up with a new entry aswell. One time I had a system with that many that I had to write a for loop to rmdev them all. hehe.

Anyway, glad you got it sorted.