0

id like to simply copy LV from one disk to another but as simply as it sounds, its becoming really abstract for me after lots of googling, to come up with the correct process. So i think i need a push to the right direction.

-how do i move lv.root do md10, i have hints that i need to expand vg.system over md10 and md20 and then copy the lv. There are lot of possibilites for vg* and lv* commands, and iam not sure which one are the best for this purpose.

Situation is:

NAME                     MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                        8:0    0 119.2G  0 disk  
|-sda1                     8:1    0     9M  0 part  
`-sda2                     8:2    0 119.2G  0 part  
  `-md0                    9:0    0 119.2G  0 raid1 
    |-vg.system-lv.root  253:0    0    30G  0 lvm   /
    `-vg.system-lv.cache 253:1    0    80G  0 lvm   /mnt/cdn-cache
sdb                        8:16   0 119.2G  0 disk  
|-sdb1                     8:17   0     9M  0 part  
|-sdb2                     8:18   0  29.3G  0 part  
| `-md10                   9:10   0  29.3G  0 raid1 
`-sdb3                     8:19   0    90G  0 part  
  `-md20                   9:20   0  89.9G  0 raid0 

expected outcome should look like cca this:

NAME                     MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                        8:0    0 119.2G  0 disk  
|-sda1                     8:1    0     9M  0 part  
`-sda2                     8:2    0 119.2G  0 part  
  `-md0                    9:0    0 119.2G  0 raid1 
    |-vg.system-lv.root  253:0    0    30G  0 lvm   /
    `-vg.system-lv.cache 253:1    0    80G  0 lvm   /mnt/cdn-cache
sdb                        8:16   0 119.2G  0 disk  
|-sdb1                     8:17   0     9M  0 part  
|-sdb2                     8:18   0  29.3G  0 part  
| `-md10                   9:10   0  29.3G  0 raid1
       vg.system-lv.root   
`-sdb3                     8:19   0    90G  0 part  
  `-md20                   9:20   0  89.9G  0 raid0 
     -vg.system-lv.cache   

Purpose is not that important i guess but just in case - later i will format sda2 and partition it the same way as sdb and merge the disk into prepared raid pools, expecting higher performance from cache partition.

EDIT: Thanks guys, i realized that the size is slightly off so i corected it, now its exact match, strange is that size is different -

NAME                     MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                        8:0    0 119.2G  0 disk  
|-sda1                     8:1    0     9M  0 part  
`-sda2                     8:2    0 119.2G  0 part  
  `-md0                    9:0    0 119.2G  0 raid1 
    |-vg.system-lv.root  253:0    0    30G  0 lvm   /
    `-vg.system-lv.cache 253:1    0    80G  0 lvm   /mnt/cdn-cache
sdb                        8:16   0 119.2G  0 disk  
|-sdb1                     8:17   0    10M  0 part  
|-sdb2                     8:18   0    30G  0 part  
| `-md10                   9:10   0    30G  0 raid1 
`-sdb3                     8:19   0  80.1G  0 part  
  `-md20                   9:20   0    80G  0 raid0 

  PV Name               /dev/md0
  VG Name               vg.system
  PV Size               119.17 GiB / not usable 1.31 MiB
  Allocatable           yes 
  PE Size               4.00 MiB
  Total PE              30507
  Free PE               2347
  Allocated PE          28160
  PV UUID               97qFfS-qcNo-Wp8W-QfWj-Ilqx-e7Jw-uMLXX7

  --- Physical Segments ---
  Physical extent 0 to 7679:
    Logical volume  /dev/vg.system/lv.root
    Logical extents 0 to 7679
  Physical extent 7680 to 28159:
    Logical volume  /dev/vg.system/lv.cache
    Logical extents 0 to 20479
  Physical extent 28160 to 30506:
    FREE

  --- Physical volume ---
  PV Name               /dev/md10
  VG Name               vg.system
  PV Size               30.00 GiB / not usable 4.00 MiB
  Allocatable           yes 
  PE Size               4.00 MiB
  Total PE              7679
  Free PE               7679
  Allocated PE          0
  PV UUID               gLYsRF-kNlb-F7c9-9BS5-Xi05-pfCY-z093pb

  --- Physical Segments ---
  Physical extent 0 to 7678:
    FREE

  --- Physical volume ---
  PV Name               /dev/md20
  VG Name               vg.system
  PV Size               80.00 GiB / not usable 4.00 MiB
  Allocatable           yes 
  PE Size               4.00 MiB
  Total PE              20479
  Free PE               20479
  Allocated PE          0
  PV UUID               vYljv8-tNc3-9jdE-p5rk-eI3y-8FVs-l1bCSF

  --- Physical Segments ---
  Physical extent 0 to 20478:

Strange. I managed to use

pvmove -v -n lv.cache /dev/md20 /dev/md0

before, and than i put it back to md0 even,because after that i used gparted to resize disks so the Total PE count matches and no overflow happens and went on.

I have two problems now. Above command is not working anymore

pvmove -v -n lv.cache /dev/md20 /dev/md0
    Cluster mirror log daemon is not running.
    Wiping internal VG cache
    Wiping cache of LVM-capable devices
    Archiving volume group "vg.system" metadata (seqno 28).
    Creating logical volume pvmove0
  No data to move for vg.system

And also iam bit worried that the slight mismatch in size ergo 80G to 80.1G will create problems when assembling into RAID pool later :/ Not sure why size is different and TOTAL PE exactly the same.

1 Answer 1

0

I think you might be better of by create new volumes and simply copying the data than attempting the following:

The steps are roughly (and untested of course, so start by checking the backups of your data) :

  • convert the new block devices to storage suitable for LVM

    pvcreate /dev/md10
    pvcreate /dev/md20
    
  • add the new storage to the existing volume group named "vg.system"

    vgextend vg.system /dev/md10
    vgextend vg.system /dev/md20
    
  • Normally you would now run pvmove /dev/md01 and vgreduce vg.system /dev/md01 to move all data away from /dev/md01 but want control over which lvm data goes where, therefore:

  • I think you can change the existing logical volumes to use a specific physical volume for the back-end storage with lvconvert:

    lvconvert --replace /dev/md01 vg.system/lv.root  /dev/md10
    lvconvert --replace /dev/md01 vg.system/lv.cache /dev/md20
    
  • confirm progress

    lvs -a -o name,copy_percent,devices 
    
  • Finally remove the md01 block device from the lv volume group and all your data should be migrated.

    vgreduce vg.system /dev/md01
    
5
  • 1
    Note that in the original question, the root LV might be just slightly bigger than the new md10 PV. As a result, using pvmove with pvmove -n lv.root /dev/md01 /dev/md10 /dev/md20 would allow any parts of the LV that won't fit into md10 to overflow into md20 in a controlled manner. After lv.root is done, you could then use pvmove -n lv.cache /dev/md01 /dev/md20 to explicitly move lv.cache to md20 only.
    – telcoM
    Sep 19, 2018 at 12:38
  • @telcoM good point that!
    – HBruijn
    Sep 19, 2018 at 12:42
  • Another note: since you are moving the root filesystem to a different disk and don't seem to have a separate /boot filesystem, you probably should recreate your initramfs/initrd after the LVM data transfer is complete. If your initramfs generator is minimalist, the initramfs might currently be configured to only start md01 before scanning for VGs and mounting the root filesystem. In this case, if the system is shut down after the move but before rebuilding the initramfs, the system would fail to boot.
    – telcoM
    Sep 19, 2018 at 12:45
  • @HBrujin: feel free to integrate my note to your answer, since the comments are not permanent.
    – telcoM
    Sep 19, 2018 at 12:45
  • thanks guys i edited the initial question, after i find solution i recreate it to be usefull for others, now iam still in a bit of problems :/
    – J B
    Sep 19, 2018 at 15:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .