Moving from one EMC frame to another.

[Doug Brinkman - DRI CMA]

We are planning to move a server from one EMC frame to another. We used SRDF to move the data. What would be the best way to proceed regarding the lvm info? Since the new EMC frame will have different device numbers, I was thinking we could vgexport -p, edit the mapfile and put the new device numbers in, then vgimport that once connected to the new frame? Does this make sense? What am I missing here.

Thanks in advance,
Ed Johnson - edward.johnson@integris.com

[harry d brown jr]

You are correct, that's what I do.

live free or die
harry

[Roger Baptiste]

Hi,

At the source end, you can do a
vgexport -p -v -s -m
(-s includes the VGID in the mapfile)

and then in the destination end(SRDF end), you can do
vgimport -v -s -m

without worrying about the disk paths. The import will scan the disks for the VGID and include them in the VG autmoatically. The import will be relatively slow in this method, if you are not in a hurry, it works fine.
Also, the pv links may not get accurately reflected with the -s option, but when we bring the system up on a SRDF copy or BCV copy, performance is not a critieria.

HTH
raj

[Sanjay_6]

Hi Doug,

When you do a vgimport you can define the device file on which this vg is currently sitting.

vgimport -m /tmp/map_name /dev/vg_name /dev/dsk/device_file

Do a "man vgimport" for more help.

Hope this helps.

Regds

[James R. Ferguson]

Hi Ed:

'vgexport' and 'vgimport' your volume groups. Consider this, using vg02, for example:

# vgchange -a n /dev/vg02
# vgexport -m /tmp/vg02.mapfile -v -f /tmp/vg02.oldpaths /dev/vg02

...then...

# mkdir /dev/vg02
# mknod /dev/vg02/group c 64 0x020000
# vgimport -m /tmp/vg02.mapfile -v -f /tmp/vg02.newpaths /dev/vg02
# vgchange -a y /dev/vg02

You can capture the "oldpaths" when you export the affected volume groups, edit the device declarations to reflect the new devices, name the edited file "newpaths" and import the volume group.

Regards!

...JRF...

[James R. Ferguson]

Hi (again) Ed:

I meant to also highlight the idea that you can declare your new devices in the order you want, balanced between channels with the alternate (pv) links established the way you want. "One-Stop-Shopping".

Regards!

...JRF...

[Deshpande Prashant]

HI
Exporting the VGs on OLD EMC frame and then importing back on new frame with new device files should help.
Use the EMC inq utility to relate device files on new frame.

Thanks.
Prashant.

[jok llamera]

hi doug,

If the two EMC were connected to each other, say R1 and R2(R1 is the source VG). You will need to split the connection on R2 first right? then
command like;

# vgexport -p -m /tmp/vg_mapfile -f /tmp/vg_pvs /dev/vg

Copy mapfiles to R2
# rcp /tmp/vg_mapfile R2:/tmp
# rcp /tmp/vg_pvs R2:/tmp

Then disable the vg on R1
# vgchange -a n /dev/vg

On R2, there might be a difference with controllers, you may edit the PV mapfile, and a command like this;

# mkdir /dev/new_vg
# mknod /dev/new_vg/group c 64 0x??0000

Test it first.

# vgimport -p -m /tmp/vg_mapfile -f /tmp/vg_pvs
# vgchange -a y /dev/vg

NOTE: if your using oracle RAW device you need to change the permissions.

# cd /dev/new_vg
# chown oracle:dba rlv's*

Hope this helps.
joks



On R2