Skip to main content

Linux - Resizing root or other File Systems with LVM

There is a lot of information about this out there about how to do LVM (Logical Volume Manager) things, and how to do file system expands and such - and it is sometimes confusing because one page will show one thing, but not all you need, an another page may show it differently, leavings some confusion to what is possible. So here is a couple of examples on how I would do it in a couple of different scenarios

Seamlessly expand partition into free space

This particular procedure only works when there is free space right after the partition you are working on - then you can do these steps:

  • Expand the virtual volume
  • Expand the partition in the OS
  • Expand the logical volume
  • Expand the file system

Not going to claim that this is universally fit for all scenarios - but very common for myself - and i found it perfectly safe for a root ext4 file system - i never tested on a root XFS, but i done it "live" on a secondary mounted xfs partition. I usually use Ubuntu Server, but i imagine most distros are similar. All the commands below must be run with sudo (or as root). Example uses /dev/sdb and other names for these examples, adjust to fit.

  1. You need to know what physical disk is your  LVM physical disk, and what volume group and logical volume you are using. Some commands to find that stuff
    1. lvmdiskscan  will show you physical partitions and what they are
    2. fdisk -l   will show you the disk, partitions, and logicals - the first thing we are looking for is the disk itself - /dev/sdb in this case
    3. pvdisplay  lists the physical configured volumes
    4. vgdisplay   lists the volume groups
    5. lvdisplay   lists the logical volumes
  2. Expand your virtual drive (in virtualbox or vcenter or similar, just up the space of the drive)
  3. Refresh disk info in Kernel, a reboot will take care of it, but why restart if we dont need to? - this can sometimes be tricky - many say that partprobe should do it, i have found it does not always work, but this command usually works fine:
    echo 1 > /sys/block/sdb/device/rescan
  4. Start the parted prompt
    parted /dev/sdb
  5. Attempt to print the current disk and partition info
  6. This should now prompt you something like this:
    Warning: Not all of the space available to /dev/sdb appears to be used, you can fix the GPT to use all of the space (an extra 1073741824 blocks) or continue with the current setting
  7. Type F to fix - the disk and partition table is now updated. Do the list command again to verify

  8. You should now see the disk as the new size, and the partition as the original size (in my case, 2TB disk, 1TB partition)
  9. Resize the partition to fill 100% - make sure the partition number matches
    resizepart 1 100%
  10. Now verify that the partition did in fact change, then exit the parted prompt
  11. This step should not be needed, but doesnt hurt anything, some say you need it in certain situations, i dont believe them but i do it anayway - refresh partition info:
  12. List your physical LVM device to verify what you are working on
  13. issue a resize command to LVM,  the physical LVM device will grow to use the full partition
    pvresize /dev/sdb1
  14. List your physical LVM device again to verify changes applied
  15. List your logical volumes to verify what you are working on
  16. Resize your logival volume to fill what is available of the volume group
    lvresize -l +100%FREE /dev/filesh17-vg/lvol0
  17. List your logical volumes again to verify the resize
  18. Resize your file system
    1. ext4:  resize2fs /dev/filesh17-vg/lvol0
    2. xfs: xfs_growfs /dev/filesh17-vg/lvol0
  19. Done - verify with
    df -h

Expand with additional physical device added to group

For all practical matters - this is probably more applicable to systems that have been used beyond its intended specs, and you need to add space to a partition or area that does not have the ability to simply grow more free space in place next to the partition needing it. Here are the steps:
  • Add device for more space, or expand space
  • In OS, Configure partition for new space so it is usable by LVM
  • Extend volume group with the new device
  • Extend logical volume
  • Extend file system
So this procedure should work for physical systems, or just by adding more disks or space to existing virtual setups. I have tested this on root file systems of type ext3 and ext4, no problem.
In the example I have a system with one disk, /dev/sda and it has been partitioned this way

  1. 200MB  /dev/sda1  ext4  /boot
  2. 475GB /dev/sda2  physical for LVM
  3. 12GB  /dev/sda3  swap

There is one volumegroup configured  /dev/konjakk-vg with 3 logical volumes
  /dev/konjakk-vg/lvroot 5GB ext4 on /
  /dev/konjakk-vg/lvvar 70GB ext4 on /var
  /dev/konjakk-vg/lvhome 400GB ext4 on /home

The root / partition is almost full and need more space. If situation allows, you could expand /dev/sda, add another partition to it, and mark as a physical devce for LVM (like /dev/sda4). But for the purpose of this example, so that it be compatible with physical hardware, we will be adding a new 200GB disk /dev/sdb.
  1. You need to know what physical disk is your  LVM physical disk, and what volume group and logical volume you are using. Some commands to find that stuff
    1. lvmdiskscan  will show you physical partitions and what they are
    2. fdisk -l   will show you the disks and partitions
    3. pvdisplay  lists the physical configured volumes
    4. vgdisplay   lists the volume groups
    5. lvdisplay   lists the logical volumes
  2. Add your disk (or space) to the system, partition the new space so it is of type for use by LVM - here is an example using fdisk on /dev/sdb
    1. partprobe
    2. fdisk /dev/sdb
      (Write new partition table if needed, GPT preferred)
    3. n : add new partition #1 - follow prompts, use entire disk
    4. t : change type to Linux LVM (8e)
    5. w : write and exit
  3. Use fdisk -l or lvmdiskscan to verify your new device is showing - /dev/sdb1 on our example
  4. When you have a device ready for LVM use, tag it as a physical device with LVM
    pvcreate /dev/sdb1
  5. Now extend your volumegroup with this device
    vgextend konjakk-vg /dev/sdb1
  6. Now extend you logical volume
    lvextend -l +100%FREE /dev/konjakk-vg/lvroot
    1. Of course, you could use lesser space than all, only extend it by a certain GB size, then leave the rest of the space to be used by other logical volumes when you need it, you could do this:
      lvextend -L +50G /dev/konjakk-vg/lvroot
      lvextend -L +100G /dev/konjakk-vg/lvvar

      and still have 100GB available in the group
  7. Resize your file system with one of these:
    1. ext4:  resize2fs /dev/konjakk-vg/lvroot
    2. xfs: xfs_growfs /dev/konjakk-vg/lvroot
  8. Done. Verify with
    df -h

(Disclaimer, it has not been tested on a root file system of type xfs)


Popular posts from this blog

Introducing Sau MGM - Small to medium Business Information technology management

I am (slowly) working on a project called SauMGM - a small/medium business IT-Department administration utility, database and more.
I will also use this blog to post helpful hints and tricks, some logs of things I have been doing, as well as a place to just store things for myself, such as remembering how to do certain things. I ofetn find myself not remembering the exact syntax on things i do occasionally, like openssl specifics.
I have been doing systems and network administration since 1999, and I am still very much hands on in all kinds of projects and technologies.

Home made SAN Migration

The topic sounds more elaborate than it is - alternative title could be "Hackjob SAN volume backup and restore".
The SetupIn a legacy-style SAN and Compute setup, I have an EMC Unity 450F box deployed with Fibre Channel (FC) to a Cisco UCS (Unified Compute System). I am booting the UCS blades off the SAN, running vmware with Block/LUN DataStores, and one blade running Windows.
I also have a Dell R740 server in the mix, with a Qlogic HBA as well as onboard storage.
The Situation Not in production yet, but we had spun up a few VMs, and all our blades had been installed, esx and vcenter running, a few VM's, and including the physical Windows blade, and the R740.

Then we discovered that the Unity had no SFP+ ports in it, and I need to do replication - swearing my vendor up and down, I call EMC, and they are sending out NIC modules and guy to install it. BUT, because we have to remove a module to insert a new one, the whole SAN box has to be reset to Factory setting (!!!). My…

New Lines - Windows/Unix/Linux/MacOS - viM

If you deal with scripts and other text files and move between platforms you probably discovered this "issue".
Only the founding developers can explain why they chose what they did - googling about will show you a couple of different explanations - whatever the reasons, here are the differences and how to convert.
The formats The Characters in use (referenced in OS info below)LF Usually referred to as LF  or Line feedAscii code decimal 10Hex: A or 0xAOctal: 12 or O12Typical Escaped character in many shells and languages: \nCRUsually referred to as CR or Carriage ReturnAscii code decimal 13Hex D or 0xDTypical Escaped character in many shells and languages: \r Unix, Linux, and Modern MacOS - The POSIX standard Each Line ends with a single character:  LF
Most programming languages will understand/interpret this format properly.
Simple Windows programs, like the built in Notepad will not show this properly.

Windows (and DOS) Each line ends with two consecutive characters in this …