lvm, persistent DSFs, and different WWIDS

[Court Campbell]

We are currently moving servers to a new data center. As a contingency we are using ca between evas in case the original eva has a fault during the move. Anyway, there is a possibility that we would have to fall back onto the ca luns that get presented to the server. I believe this would mean that the ca'ed luns would have different wwids. I know I could use a map file and vgimport top recreate things. But I was hoping that I could find another solution like scsimgr. I was wondering if anyone knows an easy way to just replace/change the wwid assicaited with a persistant dsf so that I would not have to mess aroung with lvm.

[Torsten.]

Hi Court,

IMHO there are some scsimgr commands to handle the wwid, but why not creating mapfiles with the vgid included? This is probably the easiest method.

[Court Campbell]

Hey Torsten,

We are planning on creating mapfiles. But there are many vg's on these server and I was looking for something that did not require me to recreate all the vg dirs and files. If I can just change what the dsf relationship to point to the new lun (new wwid) that seems like it would be quicker.

[Torsten.]

"replace_wwid" is probably the righht option for scsimgr here.

See the

SCSI Management and Diagnostics utility on HP-UX 11i v3

white paper (c01914672), there are similar scenarios included.

[Court Campbell]

Yeah. I got the replace_wwid idea running through my head. It's the part that I will probably have close to 9 disks that would have different wwids and not necessarily map to the same device file they had previously. what was disk54 may now be disk32. And lvmtab will have disk54. I'll do a little more digging.

I would still appreciate more ideas.

[Torsten.]

Google "c01914672"!

[Ismail Azad]

Hey court,

An export import would be the standard LVM centric way of thinking and looks like the easiest solution although I do understand it involves a lot of manual work.

> what was disk54 may now be disk32. And lvmtab will have disk54

Well I twisted around with mksf and tried this...

mksf -I 54 -C disk /dev/disk/disk32
mksf -I 54 -C disk /dev/rdisk/disk32

And this now gave 4 device files to the same disk considering both character and block. So deactivated and did an rmsf on 32. Well then ioscan now showed the device file I wanted but_obviously_lvmtab_didn't as is the problem your facing with the replace_wwid....

Although the new mass storage stack prophecises enhancements like enhanced adaptablility where the LUN expands and it informs subsystems like LVM and the associated filesystems. Apparently, the mass storage stack utilities like scsimgr apparently don't tell LVM that the device file has been changed. Well turns out to be some kind of *loophole* in the point of view of your scenario.

Well maybe there is another *simple* way to do this but the point I am trying to make is that if you want something on lvmtab to be reflected, you would have to turn to an LVM command and not utilities on the side of the mass storage stack. Just some thoughts and probably someone else has a simpler nice solution than an export/import.

Regards!
Ismail Azad

[Michael Leu]

You could use 'ioinit -f' to reassign the instance numbers. The manpage has a good example.

[Ismail Azad]

> Micheal
> ioinit -f

Well that still doesn't fix the reassigned instance being *seen* on lvmtab as a manifestation of a device file. Rather than restructuring the tree or regeneration of instances, looks like the next step is to make LVM *see* this new instance in a simple fashion with minimal steps and specificallly avoiding an export/import as I think that's what the author wants.....

Regards
Ismail Azad

[Michael Leu]

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