pvmove question

[David Irish]

Out of curiousity I was playing around with this command the other day on one of our test servers (L1000 running HP-UX B.11.00 A 9000/800). Our root volume group contains two hard drives. I was thinking it might be nice to move some LVM's from one disk to another on some of our remote production machines (located in other parts of the world). Then I read the man page on the pvmove command and was disappointed to learn that the volume group needed to be deactivated to run the command (I'm assuming this would mean being in maintenence or single user mode for the root VG?). Just out of curiosity I issued the command and was suprised when it finished successfully and the LVM/filesystem was now located on the different drive. Has anyone else tried this with success or was I just lucky? Any comments appreciated.

Thanks David

[A. Clay Stephenson · Accepted solution]

No, pvmove can be used on active VG's with mounted filesystems and is safe. The restriction is that it is not allowed when the volume group is activated in SHARED mode (ie, more than 1 host). All the disks have to be in one volume group so this does tend to limit remote transfers.

[Patrick Wallek]

Clay is absolutely correct.

I, too, have used the pvmove command with VGs active and filesystems mounted with no ill effects.

[Con O'Kelly]

Hi David

My understanding is that you can move PE's using pvmove when the VG is activated.
This is usually used to free up a disk(PV) in a VG so that it can removed and maybe added to another VG etc.

Cheers
Con

[David Irish]

Thanks guys for the clarification. I was just re-reading the man page. I've never used VG's in "shared mode". This can certainly help some of our machines. Thanks again.

David

[Colin Topliss]

Bear in mind though that you can't move physical volumes that contain lvm striping (ie lvols that have been created using the -I and -i options).

Something to watch out for if you use LVM striping, or are tempted to use it in the future.

Col.

[Marc Ahrendt]

see the following

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=73756

[Marc Ahrendt]

apologize ...my above response for for a different forum question

[Marc Ahrendt]

to make up for my mistake i do have one comment regarding pvmove

i was told it was safer to use "lvextend" and "lvreduce" to move LVs instead of "pvmove" ...the point being that if the mirroring/unmirroing process gets interrupted then you do not lose the LV integrity but if the pvmove gets interrupted then you now have a potentially messed up LV that is definitely split up amongst PVs

[David Ritchie]

Regarding pvmove corrupting LVM data - I have used pvmove extensively, and this is not consistant with my experience with the command. pvmove uses mirroring to replicate the data on an extent by extent basis - so while you may not have a complete copy
if you interrupt the pvmove, I can not think of a way that you could corrupt or lose data via use of the command.

[David Hausman]

Ditto David's comment. Since a mirror copy is created to do the move, this is a very safe operation. The pvmove, when complete, "reduces" the original copy. We have had great success with pvmove.

[Brian Butscher]

Has anyone performed a pvmove on a raw logical volume for a database like Informix? I inherited a database that has a couple of data logical volumes on the same disk with index logical volumes (not good for performance) and I want to move the data logical volumes to a disk that has just data logical volumes. Does the OS put any sort of lock (for lack of a better word) on either disk while performing this operation?

Thanks,

Brian

[David Ritchie]

>Does the OS put any sort of lock (for lack >of a better word) on either disk while >performing this operation?
>Thanks,
>Brian

There is no lock, per se - the way that pvmove works is to perform a extent by extent mirror between the old physical volume to the new. If you interrupt the pvmove operation, I would expect at most to see a pair of extents on both volumes that are mirrored. I would not expect to see any data lost or corruption.

After each extent is made current on the new physical volume, the source extent's mirror copy is broken, and then that extent is marked as being free. It really is automagical :^).

I have done this on production file systems without affecting the databases above - it is truely transparent to the applications. Now if JFS only supported doing it on a striped volume.... (I think that is one of the advantages of VxVM, BTW).

-- Dave Ritchie

[David Irish]

Brian, to answer your question. In another test I used pvmove to move the root dbspace and the log dbspace on one of our servers with no problems. The first time I took Informix offline and performed the move (successfully). The second time I left Informix up in multiuser mode and again it was successful.

David

[Brian Butscher]

I will be testing pvmove with Informix logical volumes but wanted to see if anyone else had try it successfully. Thanks for the feedback!

[Ameet_HP]

I have used this command very few times, I had no problem so far. Its so nice to move data from a disk to another & release old disk. I have not seen ot tested what happens if command is interrupted, by by my opinion, before it comes back to # prompt, LVM must be repairing the data back to original disk. Anyone's experience ?

[David Ritchie]

David, can you assign points on this top to close it out? Thanks...