DEV Community

Python-T Point
Python-T Point

Posted on • Originally published at pythontpoint.in

🐧 Resize VM Disk Ubuntu LVM — Common Mistakes and How to Fix Them

#devops #tutorial #cloud #kubernetes

Two virtual machines, running the same Ubuntu version and application stack, hit disk exhaustion. One was back online with expanded storage in under five minutes. The other remained down for hours, requiring a full rebuild. The difference wasn’t hardware, cloud provider, or administrator skill—it came down to one architectural decision at setup: LVM versus raw partitions. When you need to resize vm disk ubuntu lvm in production, Logical Volume Manager (LVM) turns what could be an outage into a routine operational task.

📑 Table of Contents

  • 🧠 LVM — Why Flexibility Matters
  • 🪛 Hypervisor — Extend the Virtual Disk
  • 🔍 Mechanism: How the Kernel Sees Resized Disks
  • ⚠️ Gotcha: Partition Table Limits
  • 🔧 LVM — Extend the Logical Volume
  • ⚙️ Mechanism: Logical Extents and Metadata
  • ✅ Verification: Check LV Size
  • 🗂 Filesystem — Grow the Root Partition
  • 🟩 Final Thoughts
  • ❓ Frequently Asked Questions
  • Can I resize the disk without LVM?
  • Do I need to unmount the filesystem to resize it?
  • What if I have multiple logical volumes and want to allocate space selectively?
  • 📚 References & Further Reading

🧠 LVM — Why Flexibility Matters

LVM abstracts physical storage into a layered model: disks become Physical Volumes (PVs) , which are grouped into Volume Groups (VGs) , and from those, Logical Volumes (LVs) are carved out as usable block devices. This abstraction enables online resizing—extending or shrinking volumes without unmounting filesystems or repartitioning disks. When the underlying virtual disk is expanded, LVM integrates the additional space by remapping Physical Extents (PEs) to Logical Extents (LEs). The kernel’s device-mapper layer handles I/O translation between the LV and the backing physical storage. Then, a filesystem resize updates internal metadata to use the larger block device. Without LVM, resizing requires adjusting partition boundaries with fdisk or parted, often demanding downtime and introducing risk if the root partition is involved. With LVM, the process is non-disruptive and idempotent. The full stack—hypervisor → virtual disk → PV → VG → LV → filesystem—enables safe, incremental growth. Each layer must be updated in sequence. 

$ sudo pvs PV VG Fmt Attr PSize PFree /dev/sda5 ubuntu-vg lvm2 a-- 29.51g 0
$ sudo vgs VG #PV #LV #SN Attr VSize VFree ubuntu-vg 1 2 0 wz--n- 29.51g 0
$ sudo lvs LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert root ubuntu-vg -wi-ao---- 27.51g swap_1 ubuntu-vg -wi-ao---- 2.00g
Enter fullscreen mode Exit fullscreen mode

These commands confirm a single PV feeding a VG with two LVs. Resizing the root filesystem starts after expanding the virtual disk.

🪛 Hypervisor — Extend the Virtual Disk

The first step in any resize vm disk ubuntu lvm procedure is increasing the virtual disk size at the hypervisor level—whether on VMware, KVM/QEMU, VirtualBox, AWS EC2, or GCP. This operation modifies the disk image (e.g., .qcow2, .vmdk) to report a larger capacity. The guest OS detects the change via a block device rescan, exposing unallocated space at the end of the disk. For KVM/QEMU with libvirt, use: 

$ virsh domblklist ubuntu-vm
Target Source
vda /var/lib/libvirt/images/ubuntu-vm.qcow2
$ qemu-img resize /var/lib/libvirt/images/ubuntu-vm.qcow2 +10G
Image resized.
$ virsh blockresize ubuntu-vm vda -size 40G
Block device 'vda' is resized to 40 GiB.
Enter fullscreen mode Exit fullscreen mode

Inside the guest, trigger a rescan: 

$ echo 1 | sudo tee /sys/block/vda/device/rescan
1
$ lsblk | grep vda
vda 252:0 0 40G 0 disk
├─vda1 252:1 0 1G 0 part /boot
└─vda2 252:2 0 29.5G 0 part ├─ubuntu--vg-root 251:0 0 27.5G 0 lvm / └─ubuntu--vg-swap_1 251:1 0 2G 0 lvm [SWAP]
Enter fullscreen mode Exit fullscreen mode

The disk (vda) is now 40G, but the LVM structures still use only ~29.5G. The ~10G of new space is unallocated.

🔍 Mechanism: How the Kernel Sees Resized Disks

Writing 1 to /sys/block/vda/device/rescan triggers the kernel to issue a READ CAPACITY SCSI command to the virtual device. The hypervisor returns the updated size, and the kernel adjusts the block device’s bd_inode->i_size. This propagates through sysfs and is reflected in lsblk. Online capacity resizing is supported for SCSI, SATA, and virtio-blk devices in modern kernels. No reboot is required.

⚠️ Gotcha: Partition Table Limits

MS-DOS partition tables cannot address disks larger than 2TB. For disks approaching or exceeding that size, use GPT. Also, ensure the extended partition (vda2) covers the full disk. If not, it must be resized. With LVM typically layered on a single large partition, run growpart to extend it: 

$ sudo growpart /dev/vda 2
CHANGED: partition=2 start=2099200 old: size=62496768 end=64595968 new: size=83875807 end=85975007
Enter fullscreen mode Exit fullscreen mode

This expands partition 2 to consume all available space, allowing pvresize to utilize the full disk.

🔧 LVM — Extend the Logical Volume

Now that the physical disk and partition are larger, update the LVM metadata to recognize the new capacity. Resize the physical volume: 

$ sudo pvresize /dev/vda2
Physical volume "/dev/vda2" changed
1 physical volume(s) resized or updated / 0 physical volume(s) not resized
$ sudo vgs VG #PV #LV #SN Attr VSize VFree ubuntu-vg 1 2 0 wz--n- 39.51g 10.00g
Enter fullscreen mode Exit fullscreen mode

pvresize scans the backing device and updates the PV's usable size. The volume group now has 10GB of free space. Extend the logical volume to use all available extents: 

$ sudo lvextend -l +100%FREE /dev/ubuntu-vg/root Size of logical volume ubuntu-vg/root changed from 27.51 GiB (7042 extents) to 37.51 GiB (9602 extents). Logical volume ubuntu-vg/root successfully resized.
Enter fullscreen mode Exit fullscreen mode

The -l +100%FREE flag allocates all unassigned extents in the VG. Using extents instead of byte sizes ensures precision, as LVM manages space in fixed 4MB units by default.

⚙️ Mechanism: Logical Extents and Metadata

Each PV is divided into Physical Extents (PEs) , usually 4MB. When extending an LV, LVM assigns free PEs to Logical Extents (LEs), updating its metadata stored in binary format on-disk and cached in /etc/lvm/backup/. The device-mapper driver maps LEs to PEs at runtime, transparently to the filesystem.

✅ Verification: Check LV Size 

$ sudo lvs LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert root ubuntu-vg -wi-ao---- 37.51g swap_1 ubuntu-vg -wi-ao---- 2.00g
Enter fullscreen mode Exit fullscreen mode

The LV is now 37.51G. But the filesystem still operates within the old boundary.

🗂 Filesystem — Grow the Root Partition

The final step is resizing the filesystem to fill the expanded block device. For ext4 , which Ubuntu uses by default: 

$ sudo resize2fs /dev/ubuntu-vg/root
resize2fs 1.46.5 (30-Dec-)
Filesystem at /dev/ubuntu-vg/root is mounted on /; on-line resizing required
old_desc_blocks = 4, new_desc_blocks = 5
The filesystem on /dev/ubuntu-vg/root is now 9833408 (4k) blocks long.
Enter fullscreen mode Exit fullscreen mode

resize2fs performs several operations: - Expands block group descriptors to cover new regions - Allocates additional inode tables - Updates the superblock with the new block count For XFS : 

$ sudo xfs_growfs /
meta-data=/dev/mapper/ubuntu--vg-root isize=512 agcount=4, agsize=1802752 blks = sectsz=512 attr=2, projid32bit=1 = crc=1 finobt=1, sparse=1, rmapbt=0 = reflink=1
data = bsize=4096 blocks=7211008, imaxpct=5 = sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0, ftype=1
log =internal log bsize=4096 blocks=3521, version=2 = sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
data blocks changed from 7211008 to 9833408
Enter fullscreen mode Exit fullscreen mode

The xfs_growfs command expands the data and inode allocation groups, recalibrating internal structures without requiring dismount. Verify the result: 

$ df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/ubuntu--vg-root 37G 12G 24G 35% /
Enter fullscreen mode Exit fullscreen mode

The system now uses the full 37G. The resize is complete.

You don’t need downtime to grow a disk—if you built it right the first time.

🟩 Final Thoughts

The ability to resize vm disk ubuntu lvm online isn’t a convenience—it’s a resilience feature. Disk exhaustion will happen. The presence of LVM determines whether the response is routine or critical. LVM introduces minimal overhead and maximum flexibility. It doesn’t replace monitoring, but it removes urgency from capacity alerts. Resizing can occur during normal hours, with no coordination, no outage. But this flexibility must be designed in. Retrofitting LVM onto a system without it requires downtime, data migration, and complex partitioning changes. So always deploy production Ubuntu VMs with LVM enabled—even for small instances. You’re not planning for current size. You’re protecting against future growth.

❓ Frequently Asked Questions

Can I resize the disk without LVM?

Yes, but it’s significantly more complex and risky. You’d need to use parted or fdisk to delete and recreate the partition with a larger size, then resize the filesystem. This usually requires unmounting the partition or booting from external media, leading to downtime. LVM avoids this by design.

Do I need to unmount the filesystem to resize it?

For ext2/3/4 and XFS , you can grow the filesystem while mounted. This is called online resizing. However, shrinking requires the filesystem to be unmounted. Always ensure you have backups before any resize operation.

What if I have multiple logical volumes and want to allocate space selectively?

You can use lvextend with specific sizes instead of +100%FREE. For example: lvextend -L +5G /dev/ubuntu-vg/var grows only the var volume by 5GB, leaving free space for other LVs. Use vgs to monitor available space.

📚 References & Further Reading

  • Ubuntu Server Guide — storage configuration including LVM and filesystems: ubuntu.com
  • Linux man pages for key tools — definitive syntax for pvresize, lvextend, resize2fs: man7.org

Top comments (0)