Swapping disk out of LVM volume group
- Published:
- categories: server
- tags: linux, lvm, system-administration
Overview
Working on upgrading my little ITX box to have some larger internal hard drives. Currently it has 2 internal drives(sdb 500G and sda 120G SSD), a USB thumb drive(sdd 16G with / and /boot), and two external USB drives (sde 2TB & sdc 1TB). Purchased a relatively cheap 4TB internal HD and want to swap out the 500GB drive for that.
The issue here is that I have fully allocated the 500G drive into a Volume Group with the 2T external USB drive to form a larger volume for storing my media to. My idea is to move away from using the USB drives full time and really use them more appropriately as “cold storage” that I can mount periodically, backup, and dismount.
Process
Since I have the drives fully allocated, it is not as simple as the LVM doc and I just use the pvmove command out of the gate, vgreduce and done. For this scenario, my primary storage space is on the USB drives so I need to plan on moving everything over to the USB drives to allow for removal of the internal drive, then replace the internal drive and move everything back into the internal storage.
List Logical Volume devices
sudo lvs -a -o+devices
List Physical Volume usage:
sudo pvs -o+pv_used
Mount your partition and determine the amount used with
df -h
First unmount and filesystems you will be touching. Then resize to larger than that so we can free up some physical extents to migrate into.
sudo lvresize --resizefs --size 800G /dev/mapper/srv--vg-root
Once I have enough space on the remaining physical volumes in the volume group, I can then use the pvmove command as expected
sudo pvs -o+pv_used
sudo pvmove -i 600 /dev/sdb1
This can take a while depending on the speed of the drives, and in my case I am moving from internal hd to usb hd via USB2 so I put the -i 600 to give me a percentage update every 10 minutes. Once it completes.
sudo vgreduce srv-vg /dev/sdb1
sudo pvremove /dev/sdb1
Now we can stop the server and physically remove the old drive, install the new drive and do the second move.
sudo fdisk
You will get a warning the DOS disklabels cannot create partitiions greater than 2TB, so we create a GPT disklabel instead which does not have the same restriction. Use the m command to see the help and how to setup a disklabel, it is very straight forward. With the new disklabel we can add a new partition n and just make it primary and consume the entire disk, so we are again left with /dev/sdb1 just now it is 3.6TiB instead of 512GiB.
sudo pvcreate /dev/sdb1
sudo vgextend srv-vg /dev/sdb1
You will want to unmount any of your filesystem again if you can, not sure this is required, but I have no need for parallel access so I did. Now we can move the data from he USB drive onto the internal HD, and remove it from the volume group.
sudo pvmove -i 600 /dev/sde1
sudo vgreduce /dev/sde1
Then we can resize our filesystem appropriately to accommodate the new size.
sudo pvs -o+pv_used
sudo lvresize --resizefs --extents +90%FREE /dev/mapper/srv--vg-root
Remount your filesystem and bask in the glory of your greatness!
Conclusion
This was not too painful, thanks to the LVM toolchain that has been put together and hardened by the community. Feeling a bit more confident the next time I need to take this on, which will be when I swap out that SSD for another large drive in the not to distant future :)