Home / Alt manpages / pvresize(8)

  • pvresize(8)
  • Admin command
  • linux

Resize an LVM Physical Volume Safely with pvresize

pvresize updates LVM's view of a physical volume after the partition underneath it changes size, and growing is far more forgiving than shrinking. Allow 10 to 20 minutes for a straightforward resize, plus whatever maintenance time your storage change needs.

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 itself normally needs sudo, and storage changes should happen during an agreed maintenance window.

Before you start: confirm the tool and the target

Confirm 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 with the storage tool appropriate to your environment; that step is outside pvresize. The PV needs 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 have active logical volumes; that is supported, but it does not by itself make the preceding partition or device change safe. Check the storage layer and the LVM reports before extending a logical volume or filesystem.

2. Preview a metadata change with test mode

To rehearse a change, 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 a live resize has happened. Only run the same command without --test after checking the target and the planned device change.

3. Shrink a PV before shrinking its partition

  • Only shrink with a specific smaller partition size already in mind.
  • 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 is 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 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 the volume group still reports the expected free space. Do not rely on a 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 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 rather than disabling locking or adding --nolocking. The manual warns that disabling locking during concurrent commands can produce incorrect results.

Done means

  • Version and PV confirmed: you checked the installed LVM version and selected the PV from current device information.
  • Growth ordered correctly: the underlying partition or device was enlarged before pvresize ran.
  • Shrink ordered correctly: the PV resize succeeded before any partition sectors were removed.
  • Result checked: you ran pvs, vgs or pvdisplay after the change.
  • No shortcuts taken: you kept a recovery path and did not use --yes or --nolocking without a specific reason.