LVM mirroring using different LUN size.

[Jeff.Z]

We got 12*55GB LUNs on the old storage, whose data needs to be migrated to new frame with 9*100GB LUNs. Is that possible to use LVM Mirroring to copy the data over?

[TwoProc]

I don't think it's going to work Jeff. Generally, after creating a volume group, larger pv's don't come in correctly when added, usually becoming part of the vg in a short-sized manner, basically being the size of the largest member of the vg when the vg was created: in this case probably 55G.

So, while you *could* do this, you'd probably waste 45G per LUN.

[Torsten.]

In general yes, but it depends.

If your VG's max values are limited to the size of the current physical devices, you cannot include larger devices in this VG.

In case you are running 11.23 or 11.31 you can use vgmodify to adjust.

If not, you should consider to backup the data, create new VGs and LVOL on the new array and restore the data.

[RobinKing]

I'd suggest using pvmove, my gut feeling is you won't be able to mirror across difference sized LUNs.

[Mike Shilladay]

Hi Jeff,

That sounds complicated. An easier solution would be to copy the data from one LUN to another. Example: mount new LUN as new_mount_point, then copy from source to new_mount_point. Once finished umount the old mount point and remount the newly created file system over the old mount point.

If you have more than one FS per LUN you will have to carry out this operation for as many FS's as you have.

Hard example:

cd
tar cf - | tar xvf -

Hope that Helps,

Mike.

[Jeff.Z]

Thank you all for the reply. let me explain a little bit about the situation in my side. We need to minimize the down time for copying data. and oracle database is running on the server. So we can't use cpio/cp/tar to copy the data over. LVM mirroring is the choice in this case. Yes, the server can support 100GB PV.

The problem is, we have 12*55GB LUNs, but only have 9*100GB LUNs. i'm going to create a PVG for those old luns, and another PVG for the new ones. Is this possible to get data copied using only 9*100GB luns or we need 12*100GB luns to get it done? Thanks much.

[Torsten.]

I'm not sure if you fully understand the problem.

The number of LUN's is not the biggest problem, but the size!

Please post a

vgdisplay -v

for that VG and we will explain it a bit better to you.

[Jeff.Z]

Torsten,

I understand what you're talking about. Yes, it can support that large devices.

It can support 156GB PV, 20TB VG in size. My question is, what the exact method for LVM mirroring within the PVG. say i have 2*50GB in one PVG, and 100GB in another, can i successfully mirror it? Thank you.

--- Volume groups ---
VG Name /dev/vg07
VG Write Access read/write
VG Status available
Max LV 255
Cur LV 2
Open LV 2
Max PV 128
Cur PV 8
Act PV 8
Max PE per PV 5000
VGDA 16
PE Size (Mbytes) 32
Total PE 14072
Alloc PE 12912
Free PE 1160
Total PVG 0
Total Spare PVs 0
Total Spare PVs in use 0

[Torsten.]

Cur LV 2
Open LV 2
Max PV 128
Cur PV 8
Act PV 8
Max PE per PV 5000
PE Size (Mbytes) 32

This looks good.
I think there are enough resources to make this work.

But ensure the LVOLs are not striped.

Just create the PVs on the new LUNs (5 LUNs should be enough for the moment).
pvcreate ...

extend the VG and create the lvmpvg file. Once this is done, mirror the LVOLs.

[Torsten. · Accepted solution]

Cur LV 2
Open LV 2
Max PV 128
Cur PV 8
Act PV 8
Max PE per PV 5000
PE Size (Mbytes) 32

This looks good.
I think there are enough resources to make this work.

But ensure the LVOLs are not striped.

Just create the PVs on the new LUNs (5 LUNs should be enough for the moment).
pvcreate ...

extend the VG and create the lvmpvg file. Once this is done, mirror the LVOLs.

[Jeff.Z]

Thanks Torsten. If i understand right, 2*50GB PVs can be mirrored to 1*100GB PV using PVG. It's a block by block copy and will NOT "waste space". Am i right?

[James R. Ferguson]

Hi Jeff:

to be perfectly clear on some of the things mentioned thus far:

1. Mirroring (in LVM) occurs at the logical volume level.

2. A 'pvmove' simply migrates logical extents from one physical volume to another, one extent at a time. It is in fact, internally some of the same code that MirrorDisk/UX uses.

3. The LVM geometry for a volume group is set during 'vgcreate' as Torsten mentioned. Until 11.31 (with 'vgmodify'; back-ported as a patch to 11.23 [PHCO_35524]) there was no way to change the LVM metadata that defines the size of a physical volume and its extents short of destroying and re-creating the volume group. Typically one would find that not all of the physical space of new, larger disks could be used when new physical devices were added to an existing volume group.

All said, if you have a configuation that provides suffient space and you don't care about un-usable physical extents; or if the new larger physical disk match the existing LVM geometry; then mirroring data to migrate from one group of physical disk to another is an excellent, high-availablity solution.

Regards!

...JRF...

[Jeff.Z]

Thanks James, crystal clear now. LV level mirroring is the point. I can mirror my 200GB lv using 2*100GB space which is equal to 2LUNs. cool.

[Sandman!]

Mirroring with different LUN sizes is certainly viable as it (and other posters have mentioned that too) will be done at the LVOL level. If the VG can utilize a 100Gb LUN without wasting space (Max PE per PV * PE Size ~ 100Gb) then you will be fine with 9 LUNs otherwise you will need 12 LUNs.

Also make sure that the LVOLs already do not have 2 mirror copies or else you would need to lvreduce one of the mirrors on the old LUN and lvextend it onto the new one. Would help if you attach the attributes of one of the lvols that you need migrated onto the new storage i.e.

# lvdisplay -v /dev/vg??/lvol??

[Jeff.Z]

thanks all, clear now.