migrating between arrays , mirrordisk ? , max PV issue

[Grant Penness_1]

Hello

I'll shortly be having to migrate disk from a StorageWorks array to EMC.

Most of my systems/volume groups should be able to use MirrorDisk, but a few have that old max_pv set to default (16) issue, so can't extend etc.

I see from browsing the forum that there is no real way around this, and am happy to just backup/restore or copy data if necessary.

but I have 1 question (well maybe 2)

would pvmove help at all with my scenario ?

anybody got any other suggestions as to how to move the data ?

thanks

[Pete Randall]

Grant,

I believe, if you look at the man page for pvmove, that the pv's have to be in the same vg. That can be a bit of a problem, but if you can work around it, it might present a possible solution for you.


Pete

[James R. Ferguson]

Hi Grant:

Using MirrorDisk/UX to replicate your data to EMC isn't going to do anything more than replicate the same LVM header information leaving your LVM geometry the same as it is currently. 'pvmove' is really a poor-man's MirrorDisk/UX insofar as 'pvmove' actually uses some of the same LVM code that MirrorDisk/UX does. Thus, 'pvmove' isn't a solution for you either. You need to "bite-the-bullet' and recreate ('vgcreate') new volume groups on your new physical disks and copy your data.

Regards!

...JRF...

[Stuart Abramson_2]

I have always migrated from the old VG to the new VG, using find/cpio online.

There are a couple of reasons:
1. Always use a technique that you can test and time in advance; that is "rerunnable" in case you have an error half-way through; and that has a "backout" option.

2. pvmove and mirror/UX alter the VG, and don't lend themselves to (1) above.

3. copying online is often faster than tape restores, where you are limited by tape speed. However, they have the disadvantage of you have to shut down the database to do the copy. So you want to know in advance how long it will take.

4. pvmove and mirror/UX are slow.

Also, on a different disk with different sizes and characteristics, you want to think about laying the disks out the best way for the new disks - which often isn't consistent with your old VGs.

[Stuart Abramson_2]

So, excuse me, I like the idea of laying out the new VGs on the new EMC and then find/cpio copy or restore from tape.

[Massimo Bianchi]

Hi,
if you can afforf some downtime, i suggest the following.

Create a new VG for the new disks. Use intelligent parameter in the creation, to allow future growth.
Create the same logical volume (same size) as the source vg

Close the application on your source FS and umount them.

Then issue as many "dd" as needed, between source and destination logical volumes.

The raw idea is a backup/restore, but using the disks directly.

Remember to use the raw device.
Pratical example:

source
/dev/vg01/lvol1 (size 500Mb)

destination
/dev/vg02/lvolnew1 (size 500Mb)

then
dd if=/dev/vg01/rlvol1 of=/dev/vg02/rlvolnew1 bs=1024k

i'm always afraid of using pvmove, if something happens in between you have lost all your data, source and destination.

Massimo

[Grant Penness_1]

I'm likeing the create new VG (sensibly !) and cpio data idea.

thanks for all the replies

[Jean-Luc Oudart]

This kind of question sometimes ago :

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x655c31bd9c1b72419b87b2bef76caca5,00.html

Rgds,
Jean-Luc

[Tom Danzig]

pvmove should work fine provided you can import one of the new devices into the volume group and not loose space due to max_pe me PV constraints.

I use pvmove to do this sort of thing quite often and it works fine. Especially handy if you don't have MirrorDisk UX. Just "nohup" it as it can take a while (a 9GB EMC RAID-S device will take about an hour).

Simply:
- vgextend one of the new EMC LUN's into the vg
- pvmove the data from one or more of the old devices to the new PV added above.
- vgreduce out the old ones freed from above step.

Should work fine. Volume group creation should always keep in mind future expandability on more/larger LUNS. Unfortunately, many admins overlook this when creation VG's.