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 are 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
    print
  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
    Fix/Ignore?
  7. Type F to fix - the disk and partition table is now updated. Do the list command again to verify
    Print

  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
    print
    quit
  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:
    partprobe
  12. List your physical LVM device to verify what you are working on
    pvdisplay
  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
    pvdisplay
  15. List your logical volumes to verify what you are working on
    lvdisplay
  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
    lvdisplay
  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 device 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)

Comments

Popular posts from this blog

Cisco UCS Mini - Add Extender Chassis

If you happen to own a UCS Mini Setup, a 5108 Chassis with two Fi 6324 or similar, and you are looking for documentation on how to add another 5108 Chassis with fabric extenders (2204XP in my case), then Cisco really does not have much out there, nor is there a lot of googlable information either (Everything you find is related to standalone Fabric Interconnects and "standard" UCS). Even after calling TAC, it took a while to get something, and what they told us was not even accurate. So here is how we did it, and it worked, came up without any interruption to current chassis, network, or running profiles. Equipment Of course we used our Cisco vendor to spec the equipment, but just for reference here is the list of what we had and what we added: Original Setup 5108 Chassis  Fi 6324 (Qty 2) Ports 1-2 for Fibre Channel, and 3-4 for Ethernet (MMF) Connected to a stack of switches and pair of FC switches/SAN Running UCS version 4.0.1 (Fairly recently upgraded as of M...

Active Directory Account Lockout - Narrowing Down the source

If you are in a all-windows shop where everything is nice and neat, everybody has a proper domain membership and all authentication is SSO or Windows Integrated, then you probably do not have much of a problem with repeated account lockouts. On the other hand, if you are in a mixed environment, lots of :Linux, Mac, and unmanaged Wintendo, then you probably run into some users that manage to Lock themselves out frequently - typically for several days in a row after the account password had been changed. Reasons can be plenty fold - typically saved credentials somewhere, like a git client, sql-server client, email client, rdp-manager, smbfs-automount, or anything that tries a bunch of logins when you start it up, or keeps trying in the background. As a sysadmin, you don't have time to narrow it down for the end user - but they will be adamant it is not their fault, so you probably need to prove that "Yes it is" - so I use powershell to grab 4740 events from Domain Con...

Campground Networking

I've travelled a couple years full time in an RV, working remotely. This can be a challenger, many campgrounds have poor Wi-Fi setups, and cell service is not always great (Do not plan on doing any work from the Grand Canyon National Park). Calling ahead and asking usually does not reveal accurate information, you are best off using campground reviews, search them for WIFI and read what people say.  The best network I have seen was at Eagles Landing RV Park in Holt, FL (Pan handle) http://eagleslandingrvpark.com/. Still not perfect. At poor sites, more than once did I offer my assistance in trying to configure and improve, but even the places which have no vendor maintain their system do not want any other hands on it. A couple of times I helped out anyway, default passwords on routers, so I upgraded their firmware, disabled 802.11b, and set a password so no-one else would mess with it. My RV network setup is not of a common type, you sort of have to be a bit of a network-guy to us...