Basically, I want to move / copy several logical volumes (lv) into a new volume group (vg). The new volume group reside on a new set of physical volumes. Does anyone know how to do that safely without damaging to the data inside those logical volumes??
There is no reason to copy it to a .img file first, just do the lvcreate first, then directly copy it over:
lvcreate --snapshot --name <the-name-of-the-snapshot> --size <the size> /dev/volume-group/logical-volume lvcreate --name <logical-volume-name> --size <size> the-new-volume-group-name dd if=/dev/volume-group/snapshot-name of=/dev/new-volume-group/new-logical-volume
Okay, I was able to handle the situation in my own way. Here are the steps I took:
1) Take a snapshot of the targeting logical volume.
lvcreate --snapshot --name <the-name-of-the-snapshot> --size <the size> /dev/volume-group/logical-volume
Note : Size of the snapshot can be as large as or as small as you wish. What matters is having enough space to capture changes during snapshot period.
2) Create an image copy of the snapshot content using
dd if=/dev/volume-group/snapshot-name of=/tmp/backup.img
3) Create a new logical volume of enough size in the targeting (new) volume group.
lvcreate --name <logical-volume-name> --size <size> the-new-volume-group-name
4) Write data to the new logical volume from the image backup using
dd if=/tmp/backup.img of=/dev/new-volume-group/new-logical-volume
5) delete the snapshot and image backup using
That's all folks... Hope this helps to someone :)
As of the LVM in Debian stretch (9.0), namely 2.02.168-2, it's
possible to do a copy of a logical volume across volume groups using a
vgsplit. Since a move is
a combination of a copy and a delete, this will also work for a move.
Alternatively, you can use
pvmove to just move the volume.
A complete self-contained example session using loop devices and
Summary: we create volume group vg1 with logical volume lv1, and vg2 with lv2, and make a copy of lv1 in vg2.
truncate pv1 --size 100MB truncate pv2 --size 100MB
Set up loop devices on files.
losetup /dev/loop1 pv1 losetup /dev/loop2 pv2
Create physical volumes on loop devices (initialize loop devices for use by LVM).
pvcreate /dev/loop1 /dev/loop2
Create volume groups vg1 and vg2 on /dev/loop1 and /dev/loop2 respectively.
vgcreate vg1 /dev/loop1 vgcreate vg2 /dev/loop2
Create logical volumes lv1 and lv2 on vg1 and vg2 respectively.
lvcreate -L 10M -n lv1 vg1 lvcreate -L 10M -n lv2 vg2
Create ext4 filesystems on lv1 and lv2.
mkfs.ext4 -j /dev/vg1/lv1 mkfs.ext4 -j /dev/vg2/lv2
Optionally, write something on lv1 so you can later check the copy was correctly created. Make vg1 inactive.
vgchange -a n vg1
Run merge command in test mode. This merges lv1 into lv2.
vgmerge -A y -l -t -v <<destination-vg>> <<source-vg>> vgmerge -A y -l -t -v vg2 vg1
And then for real.
vgmerge -A y -l -v vg2 vg1
Then create a RAID 1 mirror pair from
<> argument tells
lvconvert to make the mirror copy
lvconvert --type raid1 --mirrors 1 <<source-lv>> <<dest-pv>> lvconvert --type raid1 --mirrors 1 /dev/vg2/lv1 /dev/loop2
Then split the mirror. The new LV is now lv1_copy.
lvconvert --splitmirrors 1 --name <<source-lv-copy>> <<source-lv>> lvconvert --splitmirrors 1 --name lv1_copy /dev/vg2/lv1
Make vg2 inactive.
vgchange -a n vg2
Then (testing mode)
vgsplit -t -v <<source-vg>> <<destination-vg>> <<moved-to-pv>> vgsplit -t -v /dev/vg2 /dev/vg1 /dev/loop1
vgsplit -v /dev/vg2 /dev/vg1 /dev/loop1
lvs [...] lv1 vg1 -wi-a----- 12.00m lv1_copy vg2 -wi-a----- 12.00m lv2 vg2 -wi-a----- 12.00m
1) Most of these commands will need to be run as root.
2) If there is any duplication of the names of the logical volumes in
the two volume groups,
vgmerge will refuse to proceed.
3) On merge:
Logical volumes in `vg1` must be inactive
And on split:
Logical volume `vg2/lv1` must be inactive.
The 4 answers so far all miss that the exact size of the volume often is not known.
lvdisplay only shows values rounded to 2 decimal places and
man lvdisplay only points to other commands for available options. The following selects MiB, which is sufficiently accurate with the default LVM block size of 4 MiB:
lvdisplay --units m
MiB is also the default unit for
lvcreate. If in doubt, double check the correct size with
lvdisplay after creating the target volume. Then go ahead as in the other answers to make a copy. Furthermore, I'd recommend to verify the copy, for example with
Here why a snapshot is used and what it protects and doesn't protect:
The snapshot is made so that all data is copied as it was at the time the snapshot was created. Activities on the source volume during the copy process will not be reflected in the copy.
The snapshot also protects the source volume from human errors in the
ddcommand line. If you accidentally write to the snapshot, only the snapshot's data will be damaged and you can simply remove the snapshot and start over.
The target volume is not protected during the copy processes. If another admin (or an automatic process such as the os-prober of
dracut) mounts the incomplete volume, the mount may screw up things. (Even a read-only mount may still write journal entries to the volume.)
I will offer my own:
umount /somedir/ lvdisplay /dev/vgsource/lv0 --units b lvcreate -L 12345b -n lv0 vgtarget dd if=/dev/vgsource/lv0 of=/dev/vgtarget/lv0 bs=1024K conv=noerror,sync status=progress mount /dev/vgtarget/lv0 /somedir/
if everything is good, remove the source