Lost VG because of change adresse of disk

[Ritter Philippe]

Hello,
I just rebooted my server which is connected to an eva3000 with SecurePath 3.0e. After reboot, one of my VG was not mounted, because of the adress change :
disk 4 255/255/0/0.1 sdisk CLAIMED DEVICE HSV100 HP
/dev/dsk/c14t0d1 /dev/rdsk/c14t0d1
disk 5 255/255/0/0.2 sdisk CLAIMED DEVICE HSV100 HP
/dev/dsk/c14t0d2 /dev/rdsk/c14t0d2
disk 7 255/255/0/0.4 sdisk CLAIMED DEVICE HSV100 HP
/dev/dsk/c14t0d4 /dev/rdsk/c14t0d4


I tried vgchange, but I get :
vgchange: Warning: couldn't query physical volume "/dev/dsk/c14t0d3":

How can I change the adress ?
Thanks

[Pete Randall · Accepted solution]

my /etc/lvmtab /etc/lvmtab.old
vgscan -a

then vgchange


Pete

[Ritter Philippe]

Thanks, perfect. But how does the adress change ? Will it change after other reboot ?

[Pete Randall]

I assume you have alternate paths to your eva lun's and you may have had some sort of failure on the primary path. As a general rule, no, the paths should remain the same. I would check into your logs to see if you can find any sign of failure - perhaps one of the eva's controllers? The one time I had a similar experience, it was a controller failure on an FC60.


Pete

[Alzhy]

Aha...

One of the pitfalls of LVM.. If you were running VxVM . you will not have this issue as it nicely handles device names gracefully.

Another LVM tip though... if faced with the same scenario -- missing or renamed PV's:

Make sure your VG still has all the PVs on the system before doing anything. I do this by getting the VGID of all disks in the system that I see (ioscan -kfnC disk or via the SCSI inquire/inq command if you have it) and:

echo 0x2010?2X|adb /dev/dsk/cXtYdZ|expand|tr -d " "|sed "s/2010://"

This will ensure you still have all your disks present.

[DAUVERGNE]

I have exactly the same problem, but on several disks (EVA300+RP4440 in cluster mode) !
I 've made a small programm to solve it, because labs are looking for solution.
1 - save your mapfile every day, on both nodes if you have a cluster.
2 - look for your minor numbers.
3 - do a vgexport on your VG
4 - mkdir the nknod on your VG (take care of the minor numbers).
5 - vgimport -s -v -m mapfile VG.

May problem is not solved yet, bur I have a correspondance with support.
In SP3.0D you usually use commande like kmadmin and config to make data persistent accross reboot. In SP 3.0E this is automatic. But krsd daemon must be running to make it effective (see man pages).
here is a copy of my inittab line :
krsd:123456:respawn:/sbin/krsd -i

good luck