vgexport and vgimport with bad alternate link and mirror UX

[Vincenzo Restuccia]

I have in a machine vgORA1 with:
c4t1d0
c5t1d0 alternate link
mirrored (software) on:
c5t8d0
c4t8d0 alternate link.
node1:

ll /dev/vg*
0x030000
vgexport -p -v -s -m /etc/lvmconf/vgORA1.map /dev/vgORA1
rcp -p /etc/lvmconf/vgORA1.map host2:/etc/lvmconf/vgORA1.map


node2
mkdir /dev/vgORA1
mknod /dev/vgORA1/group c 64 0x030000

vgimport -v -s -m /etc/lvmconf/vgORA1.map /dev/vgORA1
vgchange -a r /dev/vgORA1.
After vgdisplay -v vgORA1 I see:

c4t8d0
c5t8d0 alternate link.
Why a bad alternate link ?

Thanks in advance.

[Rita C Workman]

It may very well not be a bad alternate link. It depends on the hardware path..and possibly when they connected that disk array to the other box the reversed it. They apparently did not sync up the address definitions to both boxes. But relax if your using MC/SG it will handle the difference.

If you want the info on how to do this, I could look it up and post it for you.

Regards,
/rcw

[John Poff]

Vincenzo,

I have some questions. When you do a vgdisplay -v on the first machine, it lists all four of the drives you mentioned? How many Cur PVs does it list? What output did you get when you did the vgexport and vgimport? When you do an ioscan on the second machine, does it see the c4t1d0 and c5t1d0 drives?

[James R. Ferguson · Accepted solution]

Hi Vincenzo:

I don't think there is anything "bad" or wrong other than the original alternate link is now the primary and the original primary link is now the alternate. I suspect that the switch occured after the disk were activated for some reason.

Swap the links (if you want):

# vgreduce /dev/dsk/c4t8d0
# vgextend ... /dev/dsk/c4t8d0

...JRF...

[Pedro Sousa]

Hi Vincenzo,
This has already occurred to me. It's a normal behaviour.
From the "vgimport" man page:
WARNINGS
The following warnings should only apply to the -s option when importing devices such as (NIKE) or disks with alternate path:
Since the -s option causes a search on the system for each disks with the same vg_id. When vgimport reconstruct the newly imported volume group entry in /etc/lvmtab file, the order of disks could be different than it was before. And the following will happen:
The designated primary and alternate link might not be the same as it was configured before.
Alternate links will be added to the importing volume group even if they might not be configured in the volume group initially.
If the original primary path of a disks become an alternate path after the newly imported volume group entry is created in /etc/lvmtab, the order can be easily reverted by using vgreduce to remove the primary path and then use vgextend to add the path back again.

I suppose you are not using NIKE disk array.
good luck.

[Gabriele FACCHINI]

You can make a shell script which contain the command of vgimport and the disk with the alternate path in the exactly sequence.
In the primary node you make a vgexport:
vgexport -v -p -m /tmp/map.txt vg_name > map.sh
rcp -p map.* secondary_node_name:/tmp
In the secondary node you make a vgimport with the script map.sh, that you must modify adding the first line vgimport .... and the symbol "\":
vi map.sh
vgimport -v -m/tmp/map.txt vg_name /dev/dsk/cxtydz /dev/dsk/cxtydz /dev/dsk/cxtydz
:wq!
./map.sh