lvm, persistent DSFs, and different WWIDS

[Ismail Azad]

Micheal
> Then how about just vgextending with the additional device files? If it's the same disk it should recognize it as a alternate path.

Well he is considering scsimgr and so he is typically talking about a_persistent_DSF independent of LUN path.

[Michael Leu]

Alternate paths also work with persistent DSFs :-)

Coming back to to your example Ismail, you could have vgextended /dev/disk/disk32 to the vg that has /dev/disk/disk54 and it should recongize it as a alternate path...

[Ismail Azad]

> Coming back to to your example Ismail, you could have vgextended /dev/disk/disk32 to the vg that has /dev/disk/disk54 and it should recongize it as a alternate path...

Well Micheal that doesn't work with a persistent DSF as it used to with the legacy DSF . This gives me an error associated with an LVM disk ID. :) .The whole point of a persistent DSF was that the device file represented the LUN itself and not any specific path which is why Court is worried about the WWID as that is how the LUN is authenticated on v3. My point was about the author trying to take the scsimgr route and the route I took also leads to unexpected errors.

Regards
Ismail Azad

[Michael Leu]

Ok, sorry about my total nonsense posted so far.

[Court Campbell]

Wow. I wasn't really looking for a battle of the minds. I believe we will just go with the vgexport/vgimport method. After reading the scsimgr doc it looks like a lot more work due to the multiple lun paths.

[Court Campbell]

As we all know there is more than one way to do it. But some ways are more efficient than others. Looks like the tried an true vgexport/vgimport wins again.