LVM cannot extend a logical volume: adding a PV when the VG is full

You ran lvextend and it refused with some variation of “insufficient free space” or “insufficient free extents,” while the filesystem that prompted all this sits at 99% and application writes fail. The fix is mechanical once you know which of three independent constraints is actually blocking you.

The trap is that “no space” means three different things in an LVM stack. The filesystem can be full while the LV has room. The VG can be out of free extents while every filesystem looks fine. A thin pool can be 100% full while the VG reports free space. Each constraint has a different remediation, and running the wrong one either does nothing or makes the incident worse.

This guide covers identifying which constraint you hit, the full remediation chain for a genuinely full VG (pvcreate, vgextend, lvextend, then grow the filesystem), and the allocation policy edge cases that block extension even when free space appears to exist.

What this means

lvextend allocates Physical Extents (PEs, default 4 MiB chunks) from the VG’s free pool and appends them to the LV’s segment map. It fails when the VG has zero or insufficient free extents, or when allocation policy rules prevent it from using free extents that do exist. Growing the LV does not grow the filesystem on top of it: they are separate layers, and “filesystem full” and “LV cannot extend” are independent failures that usually arrive together.

flowchart TD
  A[lvextend fails or filesystem at 100%] --> B{Filesystem full but LV has room?}
  B -- yes --> C[resize2fs or xfs_growfs only]
  B -- no --> D{VG free extents available?}
  D -- yes --> E{Thin LV and pool at 100%?}
  E -- yes --> F[Extend the thin pool LV]
  E -- no --> G[Check allocation policy and PV allocatable flag]
  D -- no --> H[pvcreate new device, vgextend, then lvextend]

Decide which branch you are on before touching anything. The quick checks below get you there in under a minute.

Common causes

Quick checks

All read-only and safe to run during an incident.

# Filesystem layer: which constraint is binding
df -h | grep -E 'mapper|Filesystem'

# Current LV sizes and (for thin) pool usage
lvs -o lv_name,vg_name,lv_size,lv_attr,data_percent,metadata_percent

# VG free space: decides whether lvextend can work at all
vgs -o vg_name,vg_size,vg_free,vg_free_count,vg_extent_count

# Per-PV free distribution: uneven spread can block striped
# or policy-constrained LVs
pvs -o pv_name,vg_name,pv_size,pv_free,pv_attr

# LV health flags: p=partial, D=thin pool out of data, F=failed, M=metadata read-only
lvs -o lv_name,vg_name,lv_attr

# Which PVs physically back an LV's segments
lvs -o lv_name,seg_pe_ranges,devices

Two caveats. First, pvs/vgs/lvs read metadata from PV headers and take VG locks, so they can hang if the underlying storage is already in trouble; dmsetup status reads from kernel memory and still works in that case. Second, transient dm device suspension during a resize is normal and sub-second, so do not panic if dmsetup info briefly shows a suspended device while another operation runs.

How to diagnose it

1. Confirm the filesystem layer. If df shows 100% but the LV is larger than the filesystem (compare df total to lvs lv_size), you do not have an LVM problem. Grow the filesystem (resize2fs for ext4, xfs_growfs for XFS) and stop. XFS can only grow, never shrink.

2. Check VG free extents. Run vgs -o vg_name,vg_free. If vg_free is zero or smaller than the requested extension, the VG is the binding constraint and you are on the add-a-PV path (or the free-up-space path). See insufficient free extents for reclaiming space before adding hardware.

3. Check whether the LV is thin. Look at lv_attr position 1 (t for thin pool, V for thin volume) or the data_percent column. If the LV lives in a thin pool and the pool’s data_percent is at or near 100%, the constraint is the pool, not the VG. Extend the pool’s data LV (lvextend against the pool LV itself); this consumes VG free extents, so recheck step 2 afterward. If metadata_percent is at 100%, that is more dangerous: metadata exhaustion can corrupt the pool, and recovery via lvconvert --repair is not guaranteed. Do not improvise on a metadata-exhausted pool.

4. If vg_free looks sufficient but lvextend still fails, check allocation policy and distribution. An LV with a contiguous or cling allocation policy cannot use free extents that violate the policy, and a striped LV needs free extents on enough distinct PVs to maintain its stripe width. A VG can show 30% free with all of it on one PV, which is useless to a striped LV. Check the LV’s allocation policy in lv_attr and the per-PV free distribution with pvs.

5. Check the PV itself. If the underlying block device was recently enlarged (cloud volume resize, SAN LUN expansion), the PV does not see the new space until you run pvresize on it. Also verify the PV is marked allocatable; a PV with allocation disabled shows it in pv_attr, and lvextend will refuse its free extents. Re-enable allocation with pvchange -x y /dev/sdX.

6. Only then run the remediation chain below.

Metrics and signals to monitor

Fixes

The VG is genuinely full: add a PV

This is the canonical chain. Each step depends on the previous one.

# 1. Stamp the new device as a physical volume
#    DESTRUCTIVE to any existing data on this device. Verify the device
#    name three times. Never pvcreate a device that holds data you need.
pvcreate /dev/sdX

# 2. Add the PV to the volume group (vgextend can also auto-initialize
#    a device that was not pvcreated, but doing it explicitly is clearer)
vgextend <vg> /dev/sdX

# 3. Confirm the VG now has free extents
vgs -o vg_name,vg_size,vg_free

# 4. Extend the LV. -r resizes the filesystem in the same step.
lvextend -L +50G -r <vg>/<lv>

#    Or consume all remaining VG free space in one go:
lvextend -l +100%FREE -r <vg>/<lv>

If you skip -r, the LV grows but the filesystem does not. Follow up with resize2fs /dev/<vg>/<lv> for ext4 or xfs_growfs <mountpoint> for XFS. Forgetting this is the most common follow-up mistake: the LV looks bigger in lvs, df shows no change, and the application keeps failing.

Tradeoffs to weigh before pvcreate:

• Physical independence. A PV on the same controller, shelf, or SAN as the existing PVs adds capacity but no failure isolation. If the VG spans failure domains, losing one device can now take out LVs that span it. Linear LVs with extents on a lost PV are immediately inaccessible.
• Reclaim first if you can. Deleting stale snapshots and forgotten LVs returns extents to the VG without new hardware. Traditional snapshots hold COW space until removed; removing one frees it immediately.
• The enlarged-device shortcut. If this is a cloud or SAN volume already resized at the hypervisor or array level, skip pvcreate entirely: pvresize /dev/sdX on the existing PV exposes the new space to the VG. Check device size against pv_size before buying disks.

The thin pool is full, not the VG

Extend the pool LV, not the individual thin LVs:

# Extend thin pool data space (consumes VG free extents)
lvextend -L +<size>G <vg>/<thinpool>

If the VG has no free extents, extend the VG first with the pvcreate/vgextend chain above, then extend the pool. If metadata_percent is the exhausted dimension, extend metadata with lvextend --poolmetadatasize, but only on a healthy pool: on a pool already in a failed state, the supported path is lvconvert --repair first, and recovery is not guaranteed. Also verify auto-extend: thin_pool_autoextend_threshold defaults to 100, which means disabled, and even a correctly configured dmeventd fails silently when the VG has no free extents to give.

Free space exists but allocation is refused

• Policy-constrained LV. Override the allocation policy for one operation with lvextend --alloc normal (or change the VG/LV policy with vgchange --alloc). The anywhere policy is a documented last resort that will use extents even at a performance cost, such as placing two stripes on one PV.
• Striped LV, uneven free space. Either add PVs so each stripe leg has room, free extents on the PVs the LV already stripes across (pvmove can relocate extents between PVs), or extend with a non-striped segment so the new space comes from wherever it is available.
• PV marked non-allocatable. Re-enable allocation on the PV with pvchange -x y /dev/sdX so its free extents become usable.

Prevention

• Alert on VG free space, not just df. VG exhaustion is a cliff: 99% works, 100% fails everything at once. Ticket below 10%, plan below 20%. See the LVM monitoring checklist for the full signal set.
• Keep headroom for the safety net. If thin pool auto-extend is your plan, the VG must hold enough free extents for at least one extension cycle, and you must have verified dmeventd is running and the threshold is actually below 100.
• Trend consumption. A VG at 80% that has not moved in months is different from one that consumed 20% last week. Runway math only works with history; the maturity model covers where trending fits.
• Audit distribution, not just totals. Periodically check per-PV free space so a striped or policy-constrained LV does not surprise you at extension time.
• Snapshot lifecycle. Traditional COW snapshots consume VG space and invalidate irreversibly at 100%. Do not leave backup snapshots around for weeks.

How Netdata helps

• Three-layer capacity view. Netdata tracks filesystem usage, VG free space, and thin pool data/metadata percentages as separate dimensions, so the alert that fires tells you which constraint is binding instead of just “disk full.”
• Trend, not snapshot. VG free space and thin pool usage are cliff-edge resources; per-second history lets you compute consumption rate and runway instead of discovering exhaustion at 100%.
• Health flag correlation. LV health attributes (p, D, F, M), PV presence, and D-state process counts collected together let you distinguish “VG full, add a disk” from “pool exhausted, processes already hanging.”
• Baseline for the remediation. After vgextend and lvextend, the dashboards confirm VG free jumped, the LV grew, and filesystem usage started dropping, so you can verify each step of the chain landed.
• Alert hygiene. Ratio-based thresholds on VG free and pool usage with the maturity-model severities keep capacity alerts actionable instead of noisy.

Related guides

• How LVM actually works in production: a mental model for operators
• LVM Insufficient free extents: the volume group is out of space
• LVM monitoring checklist: the signals every production volume manager needs
• LVM monitoring maturity model: from survival to expert