One of my clients needed to expand their DB since it was at 96% utilization. Thankfully, it was already in a volume group. Here are the steps I took to add a new LUN to the VG and expand it.
First, use fdisk to find the new LUN that doesn’t have a partition table and then use fdisk to create a new partition on it as Linux LVM:
[root@redhat ~]# fdisk -l
[trimmed]
Disk /dev/sdf: 429.4 GB, 429496729600 bytes
255 heads, 63 sectors/track, 52216 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk /dev/sdf doesn't contain a valid partition table
[root@redhat ~]# fdisk /dev/sdf
Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
Building a new DOS disklabel. Changes will remain in memory only,
until you decide to write them. After that, of course, the previous
content won't be recoverable.
The number of cylinders for this disk is set to 52216.
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)
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)
Command (m for help): p
Disk /dev/sdf: 429.4 GB, 429496729600 bytes
255 heads, 63 sectors/track, 52216 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-52216, default 1):
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-52216, default 52216):
Using default value 52216
Command (m for help): t
Selected partition 1
Hex code (type L to list codes): 8e
Changed system type of partition 1 to 8e (Linux LVM)
Command (m for help): p
Disk /dev/sdf: 429.4 GB, 429496729600 bytes
255 heads, 63 sectors/track, 52216 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sdf1 1 52216 419424988+ 8e Linux LVM
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
Syncing disks.
[root@redhat ~]# fdisk -l
[trimmed]
Disk /dev/sdf: 429.4 GB, 429496729600 bytes
255 heads, 63 sectors/track, 52216 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sdf1 1 52216 419424988+ 8e Linux LVM
Now that the partition table is setup correctly, let’s create a new LVM on the drive, and extend our existing volume group using the new physical LUN.
[root@redhat ~]# pvcreate /dev/sdf1
Physical volume "/dev/sdf1" successfully created
[root@redhat ~]# vgextend ora_vg1 /dev/sdf1
Volume group "ora_vg1" successfully extended
Here you can see our physical extents has increased due to the addition of the new physical drive to the volume group:
[root@redhat ~]# vgdisplay
--- Volume group ---
VG Name ora_vg1
System ID
Format lvm2
Metadata Areas 5
Metadata Sequence No 9
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 3
Open LV 3
Max PV 0
Cur PV 5
Act PV 5
VG Size 1.18 TB
PE Size 32.00 MB
Total PE 38555
Alloc PE / Size 25728 / 804.00 GB
Free PE / Size 12827 / 400.84 GB
VG UUID nwH9uL-gm6q-QX1y-UbLm-dkKK-wgLt-b3ZkeY
[root@redhat ~]# lvdisplay
--- Logical volume ---
LV Name /dev/ora_vg1/lvol_d03
VG Name ora_vg1
LV UUID CqjYQG-duhz-xniN-Vzha-PgVH-pcj3-vqOLar
LV Write Access read/write
LV Status available
# open 1
LV Size 749.00 GB
Current LE 23968
Segments 4
Allocation inherit
Read ahead sectors 0
Block device 253:4
I only wanted to allocated ~75% of the new LUN to lvol_d03, so I took the Current LE 23968 from the previous lvdisplay. I prefer to actually distribute via Extents, rather than the easy way of +G, etc. So I added 9827 extents (from a total of 12827 free) to the existing 23968, totaling 33795:
[root@redhat ~]# lvextend -l 33795 /dev/ora_vg1/lvol_d03
Extending logical volume lvol_d03 to 1.03 TB
Logical volume lvol_d03 successfully resized
[root@redhat ~]# lvdisplay
--- Logical volume ---
LV Name /dev/ora_vg1/lvol_d03
VG Name ora_vg1
LV UUID CqjYQG-duhz-xniN-Vzha-PgVH-pcj3-vqOLar
LV Write Access read/write
LV Status available
# open 1
LV Size 1.03 TB
Current LE 33795
Segments 5
Allocation inherit
Read ahead sectors 0
Block device 253:4
[root@redhat ~]# vgdisplay
--- Volume group ---
VG Name ora_vg1
System ID
Format lvm2
Metadata Areas 5
Metadata Sequence No 10
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 3
Open LV 3
Max PV 0
Cur PV 5
Act PV 5
VG Size 1.18 TB
PE Size 32.00 MB
Total PE 38555
Alloc PE / Size 35555 / 1.09 TB
Free PE / Size 3000 / 93.75 GB
VG UUID nwH9uL-gm6q-QX1y-UbLm-dkKK-wgLt-b3ZkeY
Above you can see we still have 3000 extents available. I tend to leave a little as wiggle room so if we ever get into a position of running out of space we aren’t screwed. 
Now that LVM has extended the volume group, we need to have the filesystem recognize it:
(This box didn’t have ext3online (older kernel; 2.6.9), so just decided to do it the old school way…)
[root@redhat ~]# resize2fs /dev/mapper/ora_vg1-lvol_d03
resize2fs 1.35 (28-Feb-2004)
/dev/mapper/ora_vg1-lvol_d03 is mounted; can't resize a mounted filesystem!
[root@redhat /]# umount /prod/d03
[root@redhat /]# e2fsck -f /dev/mapper/ora_vg1-lvol_d03
e2fsck 1.35 (28-Feb-2004)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/mapper/ora_vg1-lvol_d03: 128/98172928 files (14.8% non-contiguous), 195569167/196345856 blocks
[root@redhat /]# resize2fs /dev/mapper/ora_vg1-lvol_d03
resize2fs 1.35 (28-Feb-2004)
Resizing the filesystem on /dev/mapper/ora_vg1-lvol_d03 to 276848640 (4k) blocks.
The filesystem on /dev/mapper/ora_vg1-lvol_d03 is now 276848640 blocks long.
That’s it, now the moment of truth…
[root@redhat /]# mount -a
[root@redhat /]# df -h
[trimmed]
/dev/mapper/ora_vg1-lvol_d03
1.1T 735G 306G 71% /prod/d03
Woot, all good! (749GB to 1.1TB)
