Linux-LVM: Resize Partition to Grow LVM Volume Group

August 20th, 2012 | Tags: , , , , ,

Logical Volume Manager makes the dynamic expansion of file systems dead stupid simple.  However there is a weakness, if you are using a partitioned file system as your Physical Volume (PV) then you will end up needing to expand the file system if you ever need to grow the actual storage.  This can be avoided by using the actual physical device /dev/sda as the PV, however if this is the same volume where your /boot partition lives then you will have no choice but to partition it out since /boot cannot reside on a Logical Volume (LV).  The other way you can avoid this is by simply creating a second partition on the same disk and adding it as a new PV to the existing Volume Group (VG).  This is preferable as there is far less room for error than in this procedure, but I personally find that method a little more confusing to inherit then a straight forward single partition made an LV.

Please keep in mind that this series of changes is very high risk.  Please make sure you (1) understand fully what you are doing (2) understand fully why you are doing it (3) have backups of the data if it is of any importance to you.  If you do something stupid (even if I tell you to do it I will not be held responsible for any consequences – scared yet?).

Check our Current Configuration

Below you will see the 4 Logical Volumes, 1 Volume Group and 1 Physical Volume that we have.

# lvs
LV        VG      Attr   LSize   Origin Snap%  Move Log Copy%  Convert
lv_root  LocalVG -wi-ao 100.00G
lv_swap LocalVG -wi-ao  24.00G
lv_data1  LocalVG -wi-ao  30.00G
lv_data2  LocalVG -wi-a-  30.00G

You will see here we have ~94GB of free space in our Volume Group.  Now in this particular situation we actually have ~300GB+ due to a change in the RAID configuration (or in a more common scenario an expansion of a virtual hard disk file).

#vgs
VG      #PV #LV #SN Attr   VSize   VFree
LocalVG   1   4   0 wz--n- 278.74G 94.74G

Here is where the issue ultimately lies.  Since this OS was installed using LVM on top of a disk partition instead of the whole disk (there is no other option I am afraid when it comes to root installations).  We will need to expand the partition in order to see this on the LVM Physical Volume.

# pvs
PV         VG      Fmt  Attr PSize   PFree
/dev/sda2  LocalVG lvm2 a-   278.74G 94.74G

Make our Change Plan

Now in order to “extend” the partition we actually have to delete the partition and then recreate it.  The important part of this is that we want to ensure that when we are creating our new partition that we start it on the exact same block (we will end it on a further block, but we need to start in the right place).  Don’t try and get smart and relocate the partition in addition to extending it.  That would classify as stupid.

# fdisk -l /dev/sda

Disk /dev/sda: 598.8 GB, 598879502336 bytes
255 heads, 63 sectors/track, 72809 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1          16      128488+  83  Linux
/dev/sda2              17       36404   292286610   8e  Linux LVM

From the above output we can see a few things…

1) The disk is ~598GB
2) The last cylinder on the disk is 72809
3) The last cylinder on our (/dev/sda2) partition is 36404
4) The first cylinder on our (/dev/sda2) partition is 17
5) The type of the partition is 8e which means Linux LVM.

So this will consist of 3 changes to the partition changes.

1) Delete /dev/sda2
2) Create /dev/sda2 starting on the 17th cylinder and ending on the 72,809th cylinder (the last cylinder).
3) Set the type of /dev/sda2 to 8e.

Implement our Change Plan

Now that we know what we have to do, and we have written down all of these key details.  Keep in mind I actually mean written down on paper, if you sustain a power outage during the change you will not have a file system or a terminal window to reference the pre-existing configuration and you will need to boot to a live-cd to rebuild your partition table from your notes.

# fdisk /dev/sda

The number of cylinders for this disk is set to 72809.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)

Command (m for help): p

Disk /dev/sda: 598.8 GB, 598879502336 bytes
255 heads, 63 sectors/track, 72809 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1          16      128488+  83  Linux
/dev/sda2              17       36404   292286610   8e  Linux LVM

Command (m for help): d
Partition number (1-4): 2

Command (m for help): n
Command action
e   extended
p   primary partition (1-4)
p
Partition number (1-4): 2
First cylinder (17-72809, default 17):
Using default value 17
Last cylinder or +size or +sizeM or +sizeK (17-72809, default 72809):
Using default value 72809

Command (m for help): t
Partition number (1-4): 2
Hex code (type L to list codes): 8e
Changed system type of partition 2 to 8e (Linux LVM)

Command (m for help): p

Disk /dev/sda: 598.8 GB, 598879502336 bytes
255 heads, 63 sectors/track, 72809 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1          16      128488+  83  Linux
/dev/sda2              17       72809   584709772+  8e  Linux LVM

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.

WARNING: Re-reading the partition table failed with error 16: Device or resource busy.
The kernel still uses the old table.
The new table will be used at the next reboot.
Syncing disks.

Reboot

So hopefully you noticed that after I was done, I printed the configuration and double checked my work against my plan to ensure that I had it right.  Next we must reboot in order to re-read your partition table.

# reboot

Broadcast message from root (pts/0) (Fri Aug 10 11:25:58 2012):

The system is going down for reboot NOW!

Resize the LVM Physical Volume

OK so now that we have extended the partition and rebooted, LVM will show the same characteristics as before we extended the partition.  The next step is to perform a pvresize so that LVM will re-examine the disk characteristics of the physical volume, and then take advantage of any new space.

# pvs
PV         VG      Fmt  Attr PSize   PFree
/dev/sda2  LocalVG lvm2 a-   278.74G 94.74G
# pvresize /dev/sda2
Physical volume "/dev/sda2" changed
1 physical volume(s) resized / 0 physical volume(s) not resized
# vgs
VG      #PV #LV #SN Attr   VSize   VFree
LocalVG   1   4   0 wz--n- 557.62G 373.62G

Enjoy

That was it now, we have managed to extend the underlying partition which is the LVM Physical Volume.  This has enabled us to seamlessly extend our Volume Group, and now the full disk is being used in our environment.

  1. Tomas
    November 13th, 2012 at 08:07
    Quote | #1

    Hi,

    Thanks a lot for this exhaustive post.
    As on purpose, I was looking today for something similar.
    I managed to swap hard drives and extend up to new size with LVM on my Ubuntu machine ;)

    Cheers,
    Tomas

  2. choy
    November 15th, 2012 at 05:54
    Quote | #2

    thanks man! worked for me (Fedora 17)

  3. Justin Pryzby
    June 17th, 2013 at 15:00
    Quote | #3

    I was able to do this using cfdisk. This was a virtualbox drive. The LVM partition was under an “extended” partition. I selected the parent “extended” partition, and chose “maximize”, then selected the LVM partition and did “Resize”. “Can’t resize .. alter?” => Yes. “Where to place start” => Fixed start. Size: (maximum). Had to reboot the VM before “pvresize” would see the changes, since “partprobe” couldn’t reread the partition, since it was in use (maybe due to /boot).

  4. Pedro
    July 12th, 2013 at 20:54
    Quote | #4

    Very good =D

Comments are closed.