How to Increase the size of a Linux LVM by adding a new disk

— ny_wk

To increase the size of a Linux LVM by adding a new disk, you attach the disk, create a partition or whole-disk physical volume with pvcreate, grow the volume group with vgextend, extend the logical volume with lvextend, and finally grow the file system with resize2fs (ext4) or xfs_growfs (XFS). The entire operation runs online with zero downtime, so it is ideal for production servers that cannot be rebooted. This guide walks through the complete, accurate workflow for a VMware virtual machine and a physical server alike.

The Logical Volume Manager (LVM) is the reason this is possible. Instead of locking a file system to a single rigid partition, LVM stacks an abstraction layer between your physical disks and your file systems, letting you pool storage from multiple disks and resize on demand. Adding a new disk to an existing volume group is the cleanest way to grow space because it never touches the original disk's partition table.

The problem: a Linux LVM volume is running out of space

You have a Linux server or virtual machine whose root or data volume is nearly full. You want to extend the Linux LVM without rebuilding the machine, without rebooting, and without the risk of repartitioning the existing system disk. The safest approach is to bolt on a second disk and let LVM span both.

The example below uses a VMware VM that started with a 20 GB disk and adds a second 20 GB disk for a 40 GB total. The exact device names and volume-group names will differ on your system, but the commands and sequence are identical on any modern distribution (Debian, Ubuntu, RHEL, Rocky, AlmaLinux, SUSE).

Understand the LVM stack before you start

Three layers sit between a raw disk and your mounted file system. Getting them in the right order is the whole game:

• Physical Volume (PV) — a disk or partition initialized for LVM use with pvcreate.
• Volume Group (VG) — a pool that combines one or more PVs. You add capacity to it with vgextend.
• Logical Volume (LV) — the "virtual partition" carved out of the VG that actually holds a file system. You grow it with lvextend.

Above all of that sits the file system (ext4, XFS), which has its own size and must be grown separately after the LV grows. Forgetting this last step is the single most common reason people think the resize "didn't work."

Before you begin: back up and snapshot

The commands here can destroy data if mistyped, so protect yourself first. This is non-negotiable on production systems.

• Take a VM snapshot (vSphere: right-click the VM → Snapshots → Take Snapshot) or a full backup before touching anything.
• Verify your backups restore. A backup you have never tested is a hope, not a backup.
• Consider testing on a clone of the VM first if the workload is critical.
• Double-check device names at every step — operating on the wrong disk is the classic catastrophe.

Step-by-step: extend the Linux LVM with a new disk

1. Confirm the partition type is Linux LVM

Confirm that the volume you intend to grow is actually backed by LVM. List your disks and partitions:

1. Run fdisk -l (or lsblk -f for a cleaner view).
2. Look at the partition type. Hex code 8e means Linux LVM; hex code 83 means a plain Linux native partition.

You can also confirm the existing physical volume directly:

pvs

If the partition shows as Linux native (83) and is not part of an LVM, this guide does not apply — you would instead grow the native partition with a tool such as growpart plus resize2fs, or GParted. The rest of this article assumes a real LVM (8e).

2. Add the new virtual hard disk

In VMware vSphere, attach the disk to the running VM:

1. Right-click the VM and choose Edit Settings.
2. Click Add New Device → Hard Disk (older clients: the Add… button).
3. Set the size (20 GB in this example) and choose where to store it; defaults are fine for testing.
4. Review and click OK to apply. The disk is hot-added to the running guest.

On a physical server, simply install the new disk. SAS/SATA hot-swap bays let you do this without powering off; otherwise add the disk during a maintenance window.

3. Make the OS detect the new disk

Often the new disk appears immediately. Check with fdisk -l or lsblk — you should see a new device such as /dev/sdb with no valid partition table yet.

If it does not appear, trigger a SCSI rescan instead of rebooting:

echo "- - -" > /sys/class/scsi_host/host0/scan

You may have more than one SCSI host. To rescan all of them at once:

for h in /sys/class/scsi_host/host*/scan; do echo "- - -" > "$h"; done

If rescan-scsi-bus.sh (from the sg3-utils package) is installed, that is the friendliest option. As a last resort, a reboot always makes the disk visible.

4. Choose: whole-disk PV or a partition

You have two equally valid options for the new disk:

• Whole-disk PV (simplest, modern best practice): initialize the entire raw disk as a PV — no partitioning needed. Skip straight to step 6 and run pvcreate /dev/sdb.
• Partition first (traditional): create one partition spanning the disk and tag it as Linux LVM. This keeps the disk "labelled" so other admins see at a glance that it is in use. The original article follows this route, shown below.

Both work identically once the PV exists. Whole-disk PVs avoid an extra layer and are perfectly safe in a VM; partition-based PVs are slightly more self-documenting on physical hardware.

5. (Optional) Partition the new disk

If you chose the partition route, the modern, scriptable way uses parted with a GPT label (GPT supports disks larger than 2 TB, which the legacy MBR/MS-DOS label does not):

1. parted /dev/sdb mklabel gpt
2. parted -a opt /dev/sdb mkpart primary 0% 100%
3. parted /dev/sdb set 1 lvm on

If you prefer the classic interactive fdisk workflow (note: on an MBR disk the LVM type code is 8e; on a GPT disk it is 31 in fdisk):

1. Run fdisk /dev/sdb.
2. Press n for a new partition, then p for primary, then 1 for the partition number.
3. Press Enter twice to accept the default first and last sectors (uses the whole disk).
4. Press t to change the partition type, then enter the LVM type code (8e on MBR).
5. Press w to write the table and exit.

Verify the new partition exists with fdisk -l — you should now see /dev/sdb1.

6. Create the physical volume

Initialize the new partition (or whole disk) as an LVM physical volume:

pvcreate /dev/sdb1

Expected output: Physical volume "/dev/sdb1" successfully created. If you chose the whole-disk route, run pvcreate /dev/sdb instead.

7. Extend the volume group

First find the name of the volume group you want to grow:

vgdisplay

Look for the VG Name field (in this example it is Mega) and note the current VG Size. Now add the new PV to that volume group:

vgextend Mega /dev/sdb1

Expected output: Volume group "Mega" successfully extended. Confirm both PVs are now in the group:

pvscan

You should see both /dev/sda5 and /dev/sdb1 belonging to VG Mega, with the new PV showing its full space as free.

8. Extend the logical volume

Find the logical volume's name and current size:

lvdisplay

Note the LV Path (for example /dev/Mega/root). Now extend it. The cleanest command grows the LV to use all free space in the volume group and resizes the file system in one shot with the -r flag:

lvextend -r -l +100%FREE /dev/Mega/root

If you prefer to control the file-system resize manually (covered next), extend the LV across only the new disk like this:

lvextend /dev/Mega/root /dev/sdb1

Expected output: Logical volume root successfully resized. A quick vgdisplay/lvdisplay now shows the larger VG and LV sizes.

9. Grow the file system (the step everyone forgets)

The block device is now bigger, but the file system on top of it is not — df -h will still show the old size until you grow the file system. Pick the command that matches your file system:

• ext4 / ext3 / ext2: resize2fs /dev/Mega/root
• XFS (the default on RHEL/CentOS/Rocky/Alma 7 and later): xfs_growfs /dev/Mega/root

Both support online resizing, so the file system can stay mounted and in use. Note that XFS can only ever grow, never shrink. If you used lvextend -r in the previous step, this is already done for you.

Verification: confirm the new space is live

Prove the extension worked end-to-end with three quick checks:

1. df -h — the mount point (for example /, device /dev/mapper/Mega-root) now reports the larger capacity.
2. lvs and vgs — the LV and VG show their new sizes; the VG should report little or no free space if you consumed it all.
3. lsblk — the new disk (sdb) appears as part of the LVM stack feeding your logical volume.

Throughout this whole process the VM never needed to shut down or reboot — exactly why this is the go-to method for production servers that must stay online.

Common pitfalls when you extend an LVM

Avoid the mistakes that turn a five-minute task into an outage:

• Forgetting the file-system resize. If df still shows the old size, you grew the LV but not the file system. Run resize2fs or xfs_growfs.
• Operating on the wrong device. Always re-read lsblk before pvcreate/fdisk. Hitting /dev/sda instead of /dev/sdb can wipe a live system.
• Using xfs_growfs on ext4 or vice versa. Match the tool to the file system; check with blkid or lsblk -f first.
• Disk not detected. Rescan the SCSI bus rather than assuming a reboot is required; verify the host0 number matches your adapter.
• Trying to shrink XFS. It is impossible. To reduce space you must back up, recreate the file system smaller, and restore.
• No snapshot or backup. LVM commands are powerful and unforgiving — protect the data before you start.
• MBR 2 TB ceiling. If your new disk is 2 TB or larger, use a GPT label; an MBR/MS-DOS partition table silently caps usable space at 2 TB.

Other ways to increase Linux disk space

Adding a disk is the safest option, but it is not the only one. Choose based on your situation:

When you expand an existing disk rather than adding a new one, the key extra command is pvresize /dev/sdaX after you grow the underlying partition, so LVM picks up the additional space.

A note on legacy systems

The original walkthrough used Debian 6 ("Squeeze"), which reached end of life years ago and should not run in production today. The LVM commands themselves are unchanged and remain correct on current releases, but you should run this on a supported distribution — Debian 12, Ubuntu 22.04/24.04 LTS, or RHEL/Rocky/AlmaLinux 9. On those modern systems the default file system is often XFS (RHEL family) or ext4 (Debian/Ubuntu), so use the matching grow command. The whole-disk PV and the one-shot lvextend -r -l +100%FREE approach are the current best practice.

Key Takeaways

• The order is fixed: attach disk → pvcreate → vgextend → lvextend → grow the file system.
• Always grow the file system last with resize2fs (ext4) or xfs_growfs (XFS), or use lvextend -r to do it automatically.
• It is fully online — no reboot or downtime, which is why it is perfect for production servers.
• Snapshot or back up first and always confirm device names; LVM commands are unforgiving.
• Use lvextend -l +100%FREE -r to claim all new space and resize the file system in a single command.

Frequently Asked Questions

Do I need to reboot to extend a Linux LVM?

No. Adding a disk, creating the PV, extending the VG and LV, and growing an ext4 or XFS file system all work online while the system stays mounted and running. The only time a reboot helps is if the OS refuses to detect the newly attached disk and a SCSI rescan does not work.

What is the difference between vgextend and lvextend?

vgextend adds a new physical volume (disk/partition) into the volume group, increasing the pool of available space. lvextend then allocates some or all of that pooled space to a specific logical volume so the file system on it can grow. You almost always run vgextend first, then lvextend.

How do I grow the file system after lvextend?

Run resize2fs /dev/<vg>/<lv> for ext2/ext3/ext4, or xfs_growfs /dev/<vg>/<lv> for XFS. Both run while the file system is mounted. To skip this step entirely, add -r to your lvextend command and LVM resizes the file system for you.

Should I create a partition or use the whole disk as a physical volume?

Both are valid. Using the whole disk (pvcreate /dev/sdb) is simpler and is the modern norm in virtual machines. Creating a single LVM-tagged partition first is slightly more self-documenting on physical hardware. Functionally the result is the same once the PV is part of the volume group.

If this guide helped, subscribe to @explorenystream on YouTube for more Linux and system administration walkthroughs.