An LVM volume group on a Linux server has no free extents left. In one case the storage team presents a brand-new disk as /dev/sdc; in another they enlarge the existing disk that the volume group already sits on. What do you run in each case to get that capacity into an existing logical volume?
answer
- one layer too high: the group is full
- new disk versus same disk, bigger
- the kernel has to notice first
- VFree is the number that must move
basics
~20 sA new disk is initialised with pvcreate and joined to the group with vgextend. A disk enlarged in place needs a device rescan and then pvresize on the existing physical volume. In both cases lvextend -r is what finally moves the space into a volume.
solid answer
~50 sBoth cases end the same way, but they start differently. For a brand-new device, `pvcreate /dev/sdc` writes an LVM label on it and `vgextend vg0 /dev/sdc` adds its extents to the group. For a device that grew underneath an existing physical volume — a resized SAN LUN or a virtual disk enlarged in the hypervisor — nothing new is added; you make the kernel notice the new capacity (rescanning the device through sysfs, or rebooting), then run `pvresize /dev/sdc` so LVM re-reads the device size and claims the extra extents. After either path, confirm with `vgs` that the `VFree` column has grown, then push the space into the volume with `lvextend -r -l +100%FREE /dev/vg0/data`. If the physical volume is a partition rather than a whole disk, the partition itself has to be enlarged before `pvresize` can see anything.
code
bash · 11 lines# path one: a brand-new device joins the group
pvcreate /dev/sdc
vgextend vg0 /dev/sdc
# path two: the device the PV already sits on was enlarged
echo 1 > /sys/block/sdc/device/rescan
pvresize /dev/sdc
# either way, check the group then push the space into the volume
vgs
lvextend -r -l +100%FREE /dev/vg0/datago deeper
Know that space enters the volume group before it can reach a volume, and that a fresh disk is prepared with pvcreate and added with vgextend. Being able to name vgs as the place to check free space is enough here.
Distinguish the new-device path from the grown-device path, and explain what pvresize does that vgextend does not. Know that the kernel may need a rescan before LVM can see a larger device.
Walk the layers bottom-up — lsblk, pvs, vgs, lvs, df — and say which failure each rung catches. Raise the availability consequence of spanning a linear volume across two disks before you do it.
Own the provisioning convention: whole disks or partitions, one group per workload or a shared pool, where redundancy lives, and whether growth is automated or ticketed. Those choices decide whether this is a scripted change or a late-night improvisation.
## The question behind the question "The volume group is full" is a different problem from "the logical volume is full". `lvextend` can only hand out extents the group already owns, so when `vgs` shows `VFree` at zero, you are one layer too high. Capacity has to enter the volume group first, and there are exactly two ways in: a new physical volume joins the group, or an existing physical volume's underlying device gets bigger. ## Path one: a new device joins the group ``` pvcreate /dev/sdc vgextend vg0 /dev/sdc vgs # VFree should now show the new capacity lvextend -r -l +100%FREE /dev/vg0/data ``` `pvcreate` writes an LVM label and metadata area onto the device, making it a physical volume. `vgextend` then adds it to the named group, which is a metadata-only operation — no data moves, and it is online. From that moment the group's free extents include the new disk's, and `lvextend` can allocate from them. One consequence worth stating out loud: a linear logical volume extended onto a second disk now spans both devices. Losing either one takes the volume with it, so the reliability of the volume is now the reliability of every physical volume it touches. Where that matters, the redundancy belongs underneath LVM (RAID or a storage array) or in an LVM RAID volume type. ## Path two: the existing device grew This is the common cloud and virtualised case: the same `/dev/sdc` that is already a physical volume goes from 500 GB to 1 TB in the hypervisor or the array. Nothing needs adding to the group; LVM simply believes an old size. Two things have to happen. First the kernel must notice — a fresh block device size is not pushed at a running kernel for every transport. For SCSI-attached devices you can trigger a rescan through sysfs: ``` echo 1 > /sys/block/sdc/device/rescan lsblk /dev/sdc # should now show the larger size ``` A reboot achieves the same thing, and some virtio and NVMe devices update without any prompting. Then LVM has to re-read the device: ``` pvresize /dev/sdc pvs # PSize grows, PFree appears vgs # VFree grows by the same amount ``` `pvresize` rewrites the physical volume's metadata to cover the device's current size. It is online and safe on a live group. From there the last step is identical to path one. ## Whole disks versus partitions If the physical volume is a partition — `/dev/sdc1` rather than `/dev/sdc` — the partition table caps what `pvresize` can claim, and the partition has to be enlarged first with whatever partitioning tool the system uses. That partition-table work sits outside LVM entirely. Using whole disks as physical volumes avoids the extra step, which is one reason cloud images and storage-managed hosts often do exactly that. ## Reading the report commands The three report commands answer three different questions, and knowing which one to look at is half the skill: - `pvs` — per physical volume: `PSize` (how big LVM thinks the device is) and `PFree` (unallocated extents on it). This is where a missing `pvresize` shows up as a `PSize` smaller than what `lsblk` reports. - `vgs` — per group: `VSize` and `VFree`. This is what `lvextend` draws from. - `lvs` — per logical volume, with `lvs -o +devices` showing which physical volumes each volume's extents actually live on. ## Ordering and verification Work bottom-up and check after each rung, because each step has a distinct failure mode. The device is the wrong size (`lsblk`) → rescan. LVM believes the wrong size (`pvs`) → `pvresize`. The group has no free space (`vgs`) → `vgextend` or `pvresize`. The volume is the right size but `df` disagrees → the filesystem resize was skipped. A grow that fails is almost always a rung you did not check. ## Why -l +100%FREE deserves a moment's thought `lvextend -l +100%FREE` consumes every unallocated extent in the group. It is the convenient answer when a group serves one volume, and a decision you may regret when it serves several or when you later want free extents available for other LVM operations. On a shared group, extend by an explicit amount instead.
- How would you tell, before running anything, which of the two situations you are in?Compare the layers. `lsblk` shows the size the kernel sees for the device; `pvs` shows the `PSize` LVM has recorded for the same device. If `lsblk` is already larger than `PSize`, the device grew in place and `pvresize` is the answer. If both agree and there is simply no free space anywhere, you need a new physical volume and `vgextend`.
- What changes about a logical volume's availability once you extend it onto a second physical volume?A linear volume that now spans two devices depends on both: losing either physical volume loses the volume, since half its extents are gone. Extending across disks multiplies capacity and failure exposure at the same time. Where that matters, put redundancy below LVM with RAID or a storage array, or use an LVM RAID volume type.
- Is any of this disruptive to a running service?No, the whole chain is online. `vgextend` and `pvresize` are metadata operations, `lvextend` retargets the device-mapper table live, and both ext4 and XFS grow while mounted. The only step that can require a reboot is making the kernel see a resized device, and a sysfs rescan usually avoids even that.
saying these in an interview costs you the question
- Runs pvcreate again on a physical volume that already has data
- Thinks vgextend moves existing data onto the new disk
- Expects a resized virtual disk to appear without any rescan
- Forgets that a partition-backed PV needs the partition grown first
- Confuses vgextend with lvextend when the group is full