Using pvmove to move volumes or "lvmirror"

[Stuart Abramson]

I know this has been asked 1000 times, but I can't find the answer i want.

I have the following scenario:

We're moving to a new disk with fewer, bigger PVs.

I want to move an old VG with 28 LVs which sits on 40 old 8 GB PVs (approx 320 GB) to 5 brand new 70 GB PVs. Furthermore, the old LVs are intertwined like spaghetti on the old PVs, as over time they were extended a little bit here and a little bit there.

Let's say that:
o.. my old PVs are numbered 1-40
o.. my new PVs are numbered A-G

Can (should) I do this:
pvmove c1 cA
pvmove c2 cA
pvmove c3 cA
...etc..
pvmove c9 cB
pvmove c10 cB
...

Can you do that? Consecutive source pvmoves to the SAME target disk?

Or, should I do the mirroring with lvextend:

lvextend -m 1 lvol1 cA
lvextend -m 1 lvol2 cB
lvextend -m 1 lvol3 cB

and then lvreduce the old mirror out after.

If possible I don't want to have to calculate in advance how the PVs will fit. I'd just like to turn it loose and let it go.

I think that the lvextend/mirror/reduce option will straighten out my LVs on teh disks and be more "reliable". What happens to you if your systme crashes in the middle of a pvmove? I think that you're dead.

[RAC_1]

You can do as follows.

add bigger size pvs to exisiting vgs. But exercise a caution here. The no. of PEs count is decided at the time of vg creation unless you set it explicitely. -e option og vgcreate. If you have not, it is defaulted to 1016 or adjusted to first pv size.

So adding bigger size pvs to same vgs may not work. Also pvmove works within the vg.

So you option seems to be creating new vgs, copying the data to them, destroy the old vgs and rename new vgs as you want-vgexport and import.

Anil

[Sudeesh]

Best option is to create a new vg and add the disks there and then copy the data using cpio or do a backup and restore.

The max PE is set during vg creation and your disk add to existing vg may fail. This will prevent you from using the mirroring and pvmove.

In addition first option involves less risk, compared to pvmove and mirrioring.

Sudeesh

[Bill Hassell]

Because of he convoluted nature of the source volumes, the simplest would be to use mirroring. The reason is that the new mirror's extents will be assigned sequentially regardless of how the original extents were arranged. Once the original extents have been copied, the old lvol mirrors can be reduced.

But as mentioned, a cpio tape will also work, probably about the same speed as mirroring.

[Stuart Abramson]

Thanks for your quick responses.

Let me qualilfy my questions:

1. I know all about max_pe, max_pv, etc. My new volumes will fit in my VG.

2. I want to do the change "on-the-fly" in the middle of the day. I don't want to create new VGs.

My questions are:

1. can you do this:

pvmove c1 cA
pvmove c2 cA
pvmove c3 cA

Can you copy 3 small PVs to one big PV, one after the other, onto the same target PV? I always thought that pvmove was a one-for-one copy.

2. Is there any advantage to using the lvextend (mirror)/lvreduce method over the pvmove method? Is one faster, or more flexible or more reliable?

[Sudeesh]

If you have decided to use pvmove, here is the solution:

Assume vg02 is having lvol1, lvol2 and lvol3 residing on old disks. lvol1 is on c0t1d0. New disk added to vg02 is c2t1d0.

pvmove -n
pvmove -n /dev/vg02/lvol1 /dev/dsk/c0t0d0 /dev/dsk/c2t1d0

This move all extends of lvol1 on c0t0d0 to new disk c2t1d0.

See man pvmove for details.

Sudeesh

[Sudeesh]

further do:

pvmove -n /dev/vg02/lvol2 /dev/dsk/c0t0d0 /dev/dsk/c2t1d0

for lvol2



Sudeesh

[Stuart Abramson]

There is a KBR document on this subject, apparently, "Moving Volumes". It was mentioned in another post I found. I can't access it. Can someone send it to me, please?

[Steven E. Protter]

A document number would be helpful with your last request.

Older ITRC content is not always viable. See the monthly issues thread.

I think mirroring will solve the issue at hand.

lvextend -m 1

Then lvsplit and if needed rename and remount logical volumes.

The mirroring process may take an extensive amount of time.

SEP

[Pete Randall]

Stuart,

This one?

http://www2.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=200000080061281


Pete

[Pete Randall · Accepted solution]

Or maybe this one:

http://www2.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=200000080063168


Pete

[Doug O'Leary]

Hey;

>> 1. I know all about max_pe, max_pv, etc. My new volumes will fit in my VG.

I have to doubt that ... alot.

Unless you tweaked max_pe when you first created the volume group, it will have defaulted to a size to fit the 8 gig volumes. Just for the sake of argument, lets say it went to 3072 (more likely 2048). Assuming the standard PE_size, the largest disk you can address in that VG is 4*3072 = 12288 - or about 12 gigs.

You'll be able to add your 70 gig disk to the volume; you'll only see 15-20% of it though...

Anytime you try to add a significantly larger pv to an existing vg, you run into this issue.

You can verify your setup by attempting to add one of the 70 giggers to your existing vg then run a pvdisplay on the PV. Multiply "PE Size" by "Total PE" to find out how much space you're seeing.

HTH;

Doug

[Rita C Workman]

For your last question...

..you should be able to accomplish this by doing the pvmove command using the lvol option. Hence you move the lvols of each smaller disk to the same larger disk.

pvmove -n /dev/vg/lvol

Rgrds,
Rita

[Rita C Workman]

...and my apologies, I just noticed above that Sudeesh has actually answered your question.

Sorry,
Rita

[Stuart Abramson]

If you look closely you'll see that nobody actually answered my questions.

Pete, thanks for the pvmove KBR. The 2nd one.

My questions were:
1. Can you pvmove two small volumes to one bigger volume consecutively; one after the other.
2. Should I use lvextend mirroring or should I use pvmove? Is one faster or slower; or more or less reliable than the other?

I got too many comments about max_pe, which I already had under control...

[Doug O'Leary]

>> 1. Can you pvmove two small volumes to one bigger volume consecutively; one after the other.

Yes

>> 2. Should I use lvextend mirroring or should I use pvmove? Is one faster or slower; or more or less reliable than the other?

Personal preference. They're both reliable methods. Annecdotal personal experience suggests mirroring is slightly faster; but, I have no proof of that.

>>> I got too many comments about max_pe, which I already had under control...

That's doubtful. If you'd care to prove me wrong, post "vgdisplay ${vg}"

Doug

[Stuart Abramson]

1. You CAN move consecutive small PVs to the same larger PV:

...pvmove OldPV1 NewPVA
...pvmove OldPV2 NewPVA

2. Pro/Con mirroring vs pvmove:

a. Both move data at the same speed.
....o..In our case about 32 GB/hour.
b. Mirroring covers the risk that the system might crash in the middle of a 20 hour pvmove; which would leave the VG in an indeterminant state.

[Stuart Abramson]

.