Resize an LVM Physical Volume Safely with pvresize
You will update LVM's view of a physical volume after its partition or underlying device has changed. The common case is growing a PV after enlarging a partition. The less forgiving case is shrinking the PV before shrinking that partition. Allow 10 to 20 minutes for a straightforward resize, plus whatever maintenance time your storage change requires.
The route
Jump straight to the step you need, or tick off Done means at the end.
This guide describes the installed Ubuntu lvm2 package, version 2.03.16-3ubuntu3.2, providing LVM tools 2.03.16(2). Run inspection commands as your normal account where possible. The resize operation normally needs sudo, and storage changes should be performed during an agreed maintenance window.
Checkpoint: confirm the tool and the target
Start by confirming that the command is the one you expect and identify the exact PV device. Do not substitute a whole disk for a partition from memory. A wrong device path can update a different volume or fail in a confusing way.
$ pvresize --version
LVM version: 2.03.16(2) (2022-05-18)
Library version: 1.02.185 (2022-05-18)
$ pvs
$ lsblk
The final two commands are read-only inventory checks. Use their output to choose a path such as /dev/sdb1. The installed manual defines a PV as a device path under /dev. If the target is not obvious, stop and resolve the disk and partition layout before continuing.
1. Grow a PV after enlarging its partition
First enlarge the underlying partition or device by using the storage tool appropriate to your environment. That operation is outside pvresize. The PV must have physical space available before LVM can detect a larger size.
Once the device itself is larger, ask pvresize to use its detected size:
$ sudo pvresize /dev/sdb1
$ printf 'exit status: %s\n' "$?"
The exact status wording can vary with reporting and configuration. A zero exit status is the first check. Confirm the resulting capacity with:
$ sudo pvs /dev/sdb1
$ sudo vgs
A PV may already belong to a volume group and may have active logical volumes. That is supported by this command, but it does not make the preceding partition or device change safe by itself. Check the storage layer and the LVM reports before extending a logical volume or filesystem.
2. Preview a metadata change with test mode
For a change you want to rehearse, add --test:
$ sudo pvresize --test /dev/sdb1
TEST MODE: Metadata will NOT be updated and volumes will not be (de)activated.
Physical volume "/dev/sdb1" changed
1 physical volume(s) resized or updated / 1 physical volume(s) not resized
Test mode disables metadata writing but can still report success and can produce unusual messages in multi-stage operations because later stages read metadata that was not changed. Treat it as a rehearsal, not proof that a live resize has happened. Run the same command without --test only after checking the target and the planned device change.
3. Shrink a PV before shrinking its partition
Use the shrink workflow only when you have a specific smaller partition size in mind. The order matters: reduce or move the LVM allocation first, resize the PV metadata second, and reduce the partition last. Keep the original partition intact until the PV operation has succeeded and its result has been checked.
For example, to set a PV's size to 40 GiB:
$ sudo pvresize --setphysicalvolumesize 40G /dev/sdb1
$ printf 'exit status: %s\n' "$?"
The size input uses base-two units even when the letter's case differs: G means GiB, M means MiB, and s means 512-byte sectors. Choose a value that is appropriate for the intended new partition size. Do not copy 40G as a universal recipe.
Warning
Do not shrink the partition if this command fails. pvresize refuses to shrink a PV when allocated extents lie beyond the requested new end. That refusal protects those extents; it is a signal to inspect allocation and move or reduce the affected data before retrying.
4. Verify the result and recover safely
After a successful operation, inspect the PV and volume group again:
$ sudo pvs /dev/sdb1
$ sudo vgs
$ sudo pvdisplay /dev/sdb1
Check that the reported PV size matches the intended capacity and that the volume group still reports the expected free space. Do not rely on a command's success message alone when the next step will remove sectors from a partition.
If a shrink attempt is refused, leave the partition unchanged and investigate which logical volumes or physical extents reach the proposed end. If you successfully reduced the PV metadata but have not yet reduced the still-larger partition, the automatic form can detect the available device size again:
$ sudo pvresize /dev/sdb1
$ sudo pvs /dev/sdb1
Use that only while the underlying partition is still large enough. Once a partition has been made smaller, do not assume the old PV size can be restored. Keep backups of important data and an independent recovery path before any partition table edit.
5. Avoid prompts and configuration traps
Do not add --yes casually. It automatically answers confirmation prompts with yes, which is risky in scripts and when a device path may be wrong. Use --verbose when you need more detail, or --reportformat json when a program needs structured report output:
$ sudo pvresize --reportformat json /dev/sdb1
$ sudo pvresize --verbose /dev/sdb1
Keep the target explicit in automation. LVM may also be restricted by a devices file or by options in /etc/lvm/lvm.conf; a device that exists in lsblk can still be invisible to the command. Use the command's diagnostics to investigate that situation rather than disabling locking or adding --nolocking. The manual warns that disabling locking during concurrent commands can produce incorrect results.
Done means
- You confirmed the installed LVM version and selected the PV from current device information.
- For growth, the underlying partition or device was enlarged before
pvresizeran. - For shrinkage, the PV resize succeeded before any partition sectors were removed.
- You checked
pvs,vgsorpvdisplayafter the change. - You kept a recovery path and did not use
--yesor--nolockingwithout a specific reason.