Fixing Missing Volume Group - PVlinks

[Andrew Moody_1]

This weekend the SAN admin migrated from brocade to cisco fabric. All Securepath devices managed fine with migration, however one volume group was accessed via pvlinks and is currently unavailable.

OS 11.11 - vg05 was setup with 1 primary and 7 alternates. Can't add new alternates because using max number already. Won't let me vgreduce (-l) on volume group, error is

Device file path "/dev/dsk/c41t0d1" is an alternate path.
vgreduce: Couldn't delete physical volume:
No such device or address

Which means I can't add any of the new paths to get the volume group up and running. Not sure where to go with this?

[Duncan Edmonstone · Accepted solution]

Andrew,

Are any of paths still visible - or have they all changed?

If they're all chnaged, you're going to have to export the volume group and re-import it:

ll /dev/vg05/group

Note down the device minor number (0xnn0000)

vgexport -m /tmp/vg05.map vg05

Then re-create:

mkdir /dev/vg05
mknod /dev/vg05/group c 64 0xnn0000

using the minor number you noted down before

Then vgimport the VG using the new device paths:

vgimport -m /tmp/vg05.map /dev/vg04 /dev/dsk/cXtYdZ ... etc


HTH


Duncan

[Andrew Moody_1]

Duncan

Should our paths ever cross then those 10 points above will be supplemented with a large drink.

Many thanks

[Eric SAUBIGNAC]

Andrew,

BE AWARE that if you reboot the server, VG with path managed by autopath will probably not activate .... !!!!

I guess that if you issue an autopath display you will see half paths (8 ?) in a failed state. The failed path are the old ones, correspondig to the brocade SAN. The Active path are those corresponding to the new cisco SAN.

When you will reboot your server, autopath will probably manage and display only the valid pathes, that is those correspondig to the only cisco SAN. autopath will have no knowledge of the old special files.

Since you had no trouble during the migration because of autopath, your VG are probably still configured with the old naming convention through the brocade SAN. Since autopath will not handle those old path, vg will not activate :-(

I STRONGLY SUGGEST THAT YOU VERIFY YOUR VG CONFIGURATION BEFORE ANY REBBOT. If it is necessary to repare, just add one new path in the VG. LVM will see it as an alternate path, check with vgdisplay. Once done simply remove the old link.

Hope you will find this post and it will help.

Regards

Eric

[Andrew Moody_1]

Eric

We don't use autopath.

We use SecurePath to an EVA3000 and pvlinks to the EVA8000. SecurePath managed the fail over seamlessly and the boxes have been rebooted several times since.

Thanks for the advice though.

[Eric SAUBIGNAC]

Ok, Andrew

It is fine like this :-)

The product formally known as Securepath has 2 mode of installation :

- active/passive --> securepath, spmgr, etc ...

- active/active --> autopath, etc ...

So, when someone speaks of Securepath, I think to both spmgr and autopath. That's why I did the mistake.

But, since you have Securepath active / passive installed onto your system, you can also insall Securepath active / active to manage failover and load-balancing to the EVA 8000. Both products can work on the same system without any trouble. The main difference is that autopath doesn't create a pseudo device as securepath does. That's why you had no trouble with EVA 3000's luns : the pseudodevice name doesn't change

Regards

Eric