Showing results for 
Search instead for 
Did you mean: 

SAN migration on Service guard

Go to solution

SAN migration on Service guard



While migrating the SAN on service guard environment....its just a vgexport &  vgimport will be enough?


Anything else to be done apart?


I request to provide the step by step procedure and i hope that will give a clear picture.


Thanks & Regards,

Karthik Balu.

Ralf Seefeldt
Valued Contributor

Re: SAN migration on Service guard



In most cases, I would say yes, you are right.

I assume that your new disks (raw devices, not filesystem level) already hold a copy of the old ones.

You should use the -s and  -m option for vgesport and vgimport and work with the created mapfile. Use the -p (preview) option for this export. If that works fine, realy export the

If you stay on the same server and want to keep the VGname, you have to get rid of the old disks/LUNs bevore importing the new VG.

You should be sure, that your disks or LUNs are presented to the new server and will be unpresented from the old server AFTER all is fine AND AFTER removing any no longer needed devicefiles from the old server.


An alternative way would be to add one set of the new LUNs (assuming you have two sets and want to be mirrored) as 2nd mirror to your VG.

Than remove the original disks that come from the same datacenter as your new disks.

Than add the new disks from the 2nd datacenter (if you want to be mirrored)

and remove the original disks from the 2nd datacenter.

This works without vgimport / vgexport. But you should have PVGs configured.

All this would work on a productive system without downtime and with little effect to the responsetime of the disks. But better us a time with low traffic on the disks and be prepared to wait for about 15 to 60 minutes for each TB.


All depends on what you are realy want to do and what your environment looks like.







Patrick Wallek
Honored Contributor

Re: SAN migration on Service guard

>>While migrating the SAN on service guard environment


What exactly do you mean by this?  Are you moving to a new SAN?  More details will allow us to give you better information.


Re: SAN migration on Service guard

Yes Patrick....we are going to remove the old san(EMC Cx3) luns and present the new(VNX5500) luns.

Stephen Doud
Honored Contributor

Re: SAN migration on Service guard

The least interruptive method to migrate to a new array is to

1) add LUNs from the new array into the active package VG. 

2) mirror volumes in the VG to the new array LUNs

3) lvreduce the old LUNs (1st copy) out of the volume(s)

4) vgreduce the old array LUNs out of the VG.

5) Update the /etc/lvmtab on the other node(s)


Example steps:  (where  c6t3d0 is a new array LUN)
Node1: pvcreate /dev/rdsk/c6t3d0   # prep new LUN for use with LVM

Node1: vgextend /dev/vg01 /dev/dsk/c6t3d0

Node1: ioscan -fnCdisk    # identify the old array LUN device special files (DSFs), and new array DSFs

Node1: vgdisplay -v /dev/vg01 # identify the disks used by the VG

Node1: lvdisplay -v /dev/vg01/lvol1  # identify the logical volumes on each disk

Node1: lvextend -m 1 /dev/vg01/lvol1 /dev/dsk/c6t3d0   # create a mirror of lvol1 (on c2t0d0) onto c6t3d0

Node1: lvdisplay -v /dev/vg01/lvol1 # confirm all extents are mirrored to c6t3d0

Node1: lvreduce -m 0 /dev/vg01/lvol1 /dev/dsk/c2t0d0  # remove the 1st copy of lvol1 data from the old LUN

Node1: lvdisplay -v /dev/vg01/lvol1 # confirm all extents in the lvol are only on c6t3d0

Node1: vgreduce /dev/vg01 /dev/dsk/c2t0d0

Node1: vgexport -pvs -m /etc/lvmconf/ /dev/vg01  # create an LVM map file

Node1: scp /etc/lvmconf/ root@Node2:/etc/lvmconf/   # copy the file to the other node


Node2: ll /dev/*/group   # record the minor number of vg01  (eg. 0x010000)

Node2: vgexport vg01   # remove it from /etc/lvmtab

Node2: mkdir /dev/vg01 ; mknod /dev/vg01/group c 64 0x010000 # use previous group minor number # use correct major and minor number

Node2: vgimport -vs -m /etc/lvmconf/ /dev/vg01


NOTE: Test these instructions on a dummy VG * lvol  and modify to suit before implementing on real data volumes.


The cluster ASCII configuration file does not have to be modified unless the cluster uses a cluster lock disk and it is moving to the new array.  In this case, update the FIRST_CLUSTER_LOCK_PV reference for each node, and cmapplyconf the file to install a cluster lock structure on the new array LUN/VG.


This method allows the VG to remove active, and it's file systems mounted and usable throughout the procedure.