Hello,
We need to migrate to a new storage frame and i'd like to do it with no/little downtime. The existing vg contains 1 lv that is spread across 4 disk devices. I have allocated and added 1 new disk to the vg that I want to migrate to. I used lvconvert to do this. Once lvconvert showed 100% sync I then used lvconvert to pull the original 4 drives. After, the vgdisplay command shows the vg/lv on the original and the new device empty. Any suggestions on what i'm doing wrong and how I can get this done? Here are the commands I used:

lvconvert -m 1 vgname/lvname /dev/mapper/mpathg

after sync:
lvconvert -m 0 vgname/lvname /dev/mapper/mpathp
lvconvert -m 0 vgname/lvname /dev/mapper/mpathk
lvconvert -m 0 vgname/lvname /dev/mapper/mpathr
lvconvert -m 0 vgname/lvname /dev/mapper/mpaths

The server is running RedHat 6.4

Thanks,
Tom.

For multiple PVs on the same LV use one line to remove them from the mirror:
When we did a similar migration last year I found that any typo in the "lvconvert -m 0" makes it go back to the first (original) mirror device(s) rather than keeping the new mirror. Quite maddening on some of the things I did that were 7 TB and took hours to create the new mirror.

1 members found this post helpful.

Mirroring and then removing the original is basically what pvmove does.

There is benefit to using lvconvert vs pvmove:
1) You can background the lvcconvert and periodically check its status.
2) You can work with multiple LVs more easily.
3) If something happens in the middle of the lvconvert your original extents are still in place until you decide to remove the extents on the new volumes.

pvmove is something I've used a few times for one off things (e.g. moving from a smaller volume to a larger one) but for a project where one is migrating from one disk array to another where multiple servers, multiple VGs and multiple LVs are concerned lvconvert is the way to go IMO.

If you don't restrict it to one LV, pvmove will happily move all the LVs in the source PV. If there is a crash during the operation, just running "pvmove" again with no physical volume arguments will restart all moves in progress from the last checkpoint. You can use the "--atomic" option to ensure that everything remains as it was on the source PV if the operation is aborted. You can use the "--background" option to run the pvmove daemon in the background.

Yes, you can do it all manually with lvconvert, just as you can use dmsetup directly to make COW snapshots without involving LVM. Generally, using the higher-level tools makes more sense to me unless there is some overriding reason that prevents it.

Thank you, this worked.

1 members found this post helpful.