Skip to main content
LVM

Migrating LVM Volumes

By August 25, 2017September 12th, 2022No Comments

Migrating LVM VolumesAnother really great feature of LVM2 is being able to migrate data to new hardware whilst the Logical Volumes are online. Migrating the data is likely to be happen when we add new solid state storage into the system. We probably can retire the old spinning hardware but we will need to move that data first. With the need for 7 day a week and 24 hours a day access to your data required you don’t want to unmount your volumes. Rather than just leave the data on the old hardware we can make use of the command pvmove to, well move, the data from one PV to another. If you are interested in the previous lesson we looked at provisioning LVM Thin Volumes

Follow the link below to download the ‘Complete Guide to LVM2 in Linux’, costing just £1.99! Once it is downloaded the eBook can be printed out if required.

Download eBook

Create the Volume Group

Even though there is no need to create the Volume Group from scratch, we will begin with a new Volume Group and add the Physical Volumes and Logical Volumes in from scratch so we understand the process. For the demonstration process we will be using the two file devices again as Physical Volumes, /dev/loop0 and /dev/loop1. In reality, if we are migrating from spinning hardware to SSDs; these would be two disk devices or partitions on different disk drives. The process is the same no matter what PVs you use.

# vgcreate vg2 /dev/loop0
   Volume group “vg2” successfully created

Our Volume Group is created from the single PV /dev/loop0. This can represent the old spinning hardware that we are currently using. The disk files were created at 100 MiB so we will have 96 MiB free as we will use one extent for the VG Metadata by default.

Create and Mount the Volume

We will now run through the process of creating the Logical Volume. This will be formatted with EXT4 before we mount it and add data.

# lvcreate -l 100%FREE -n data1 vg2
   Logical volume “data1” created

We have created the LV to the fill the extent size of the VG, although it really does not matter the size that we create the LV at. We then format it with EXT4:

Now, we will now create a mountpoint and mount the LV to that directory:

# mkdir /data && mount /dev/vg2/data1 /data

To add data we will copy across all the .conf files from /etc directory. Just as an example:

# find /etc -maxdepth 1 -name ‘*.conf’ -exec cp {} /data \;

We can view this data by listing the /data directory:

# ls /data
 adduser.conf            fuse.conf        ld.so.conf      nsswitch.conf            sysctl.conf
 ca-certificates.conf    gai.conf         libaudit.conf   pam.conf                 ucf.conf
 debconf.conf            hdparm.conf      logrotate.conf  popularity-contest.conf  updatedb.conf
 deluser.conf            host.conf        lost+found      resolv.conf
 discover-modprobe.conf  insserv.conf     ltrace.conf     rsyslog.conf
 e2fsck.conf             kernel-img.conf  mke2fs.conf     sensors3.conf

So, we have data and the old hardware is up and running. The good news is that we have new hardware to migrate to.

Migrating LVM Volumes

If we check the current usage of the Logical Volume data, it will entirely be located on /dev/loop0. That is simple enough to understand as we only have the single device in the Volume Group.

# lvs vg2 -o +devices
   LV    VG   Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert Devices      
   data1 vg2  -wi-ao---- 96.00m                                                     /dev/loop0(0)

We will start by adding in the new PV to the vg2 Volume Group:

# vgextend vg2 /dev/loop1
   Volume group “vg2” successfully extended

This will only affect the free space in the VG and will not move the data:

# lvs vg2 -o +devices
   LV    VG   Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert Devices      
   data1 vg2  -wi-ao---- 96.00m                                                     /dev/loop0(0)

To move the underlying data we use the command pvmove:

# pvmove -n data1 /dev/loop0 /dev/loop1
   /dev/loop0: Moved: 100.0%

The move has taken place whilst the Logical Volume was mounted and the data was online. We can check that it is still there and crucially nothing has changed to the outside world. The LV name is the same, the devmapper name is the same. The PV is always going to be abstracted from the software that uses them.

# ls /data
 adduser.conf            fuse.conf        ld.so.conf      nsswitch.conf            sysctl.conf
 ca-certificates.conf    gai.conf         libaudit.conf   pam.conf                 ucf.conf
 debconf.conf            hdparm.conf      logrotate.conf  popularity-contest.conf  updatedb.conf
 deluser.conf            host.conf        lost+found      resolv.conf
 discover-modprobe.conf  insserv.conf     ltrace.conf     rsyslog.conf
 e2fsck.conf             kernel-img.conf  mke2fs.conf     sensors3.conf

The underlying data was moved between devices whilst the data was in use and mounted. Quite impressive.

Remove the Old Hardware

To make sure that the old hardware is not used in the VG, we can remove it from the Volume Group:

# vgreduce vg2 /dev/loop0  Removed “/dev/loop0” from volume group “vg2”

As a final check, we can show the devices used by the LV:

# lvs vg2 -o +devices
   LV    VG   Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert Devices      
   data1 vg2  -wi-ao---- 96.00m                                                     /dev/loop1(0)

The output is the same, other than we are now pointing to /dev/loop1.
LVM Administration