[custom-header-login]
Another 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.
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.
