PVMOVE info

[Fern H2O]

Hello Everyone,

Here's the deal:

In vg02 I have 26 Disks 50GB/each.
13 are currently in use and 13 are completely empty, because i just added them.

I want to move all data from the currently used 13 disks to the new ones I just added.

Usually we would create a new VG with the new disks, umount FS's and dd LV to LV. This is obviously alot of work since you have to make sure that new VGs, LVs and FS's are created equal or greater than the old one, so it's more prone to mistakes. Also, it requires alot of downtime.

This time I want to use the command PVMOVE (no downtime). It sounds very simple since its just pvmove disk_old to disk_new. My question is, can I run more than one pvmove at a time? For example open up 3 or 4 telnet windows and run a different pvmove on each one? Or is that not allowed?

I have never used this command before so any advice/tips would be greatly appreciated. If anyone has done this before please share some examples on how you did it and your experience on it.

Thanks,

[Patrick Wallek · Accepted solution]

No, you can't run more than 1 pvmove at a time. This is becuase in the background the pvmove is doing, basically, an LVM mirror operation. Only one LVM operation can be run at a time.

I have used pvmove in the past and it has worked well.

Be aware, though, that there can be complications if the pvmove is interrupted for some reason. I would be tempted to run the pvmoves from the system console (GSP/MP, web or direct attached) so that an interruption of your telnet window will not adversely affect the pvmove.

[Fern H2O]

Also, what if something happens during the pvmove, like telnet disconnects, will the data be lost or be left in some kind of interupted state?

If anyone has another suggestion on how to migrate, please let me know as well.

thanks again.

[Fern H2O]

One More Thing,

These EMC NS480 Disks, Raid 5.

I don't think that should matter but just in case...

[Patrick Wallek]

The type of disk shouldn't matter that much.

I don't know that I would necessarily do the pvmoves during peak production usage. This can be a fairly intense I/O operation so access times could be slowed by the pvmove.

[James R. Ferguson]

Hi:

If you are licensed for LVM's mirroring then you should consider using it to replicate your data.

One caveat with using either 'pvmove' or 'lvextend -m' is that the your new physical volumes will have the same LVM geometry ('max_pe', 'pe_size', etc) as your original ones since you will be 'vgextending' new volumes into the volume group to use ;ogical volume maintenance tools. If you are on 11.23 or later, of course, you can use 'vgmodify' to change some of the geometry.

You may want to talk with EMC too, since they have data migration tools that may better suit your needs.

Regards!

...JRF...

[Fern H2O]

Thanks for the replies.

Basically, what I'm getting is its a good command BUT it COULD leave my data trashed if interrupted. Which leaves me feeling nervous...

I have here a quote from HP that says,

"pvmove guarantees "atomic" moves. pvmove won't leave your data in an inconsistent state if the command is interrupted for any reason."

So... has anyone's disk migration using pvmove gone awry??

[James R. Ferguson]

Hi (again):

> I have here a quote from HP that says,
"pvmove guarantees "atomic" moves. pvmove won't leave your data in an inconsistent state if the command is interrupted for any reason."
So... has anyone's disk migration using pvmove gone awry??

What are you asking? If you don't believe the documentation, perform an experiment where you interrupt/terminate an ongoing 'pvmove'. As Patrick said, precautions protect.

Regards!

...JRF...

[Fern H2O]

Thanks everyone