Add a Physical Volume to an LVM Volume Group with vgextend

A volume group that is quietly running low on free space is not a crisis until someone tries to grow a logical volume and hits a wall. vgextend is the fix: it adds one or more physical volumes (PVs) to an existing LVM volume group (VG) so there is room again. The examples use LVM 2.03.16(2), installed here from the Ubuntu lvm2 package version 2.03.16-3ubuntu3.2.

Allow about fifteen minutes once you have a prepared PV. This guide does not partition a disk, create filesystems or extend a logical volume; that is separate work for after the group has grown.

• You need: a shell with elevated privileges for the metadata change.
• An existing volume group plus a device you can positively identify as the intended PV.

1. Check the installed command

Start with read-only checks. These do not need sudo:

$ vgextend --version
  LVM version:     2.03.16(2) (2022-05-18)
$ vgextend --help
  vgextend - Add physical volumes to a volume group

The installed syntax is vgextend VG PV .... A PV is normally a device path under /dev. The command accepts several PVs in one invocation.

$ command -v vgextend
/usr/sbin/vgextend
$ dpkg-query -W -f='${Package} ${Version}\n' lvm2
lvm2 2.03.16-3ubuntu3.2

2. Identify the volume group and candidate device

List the current groups and PVs before touching anything:

$ vgs
$ pvs -o pv_name,vg_name,pv_size,pv_free,pv_uuid
$ lsblk -o NAME,PATH,SIZE,TYPE,FSTYPE,MOUNTPOINTS,MODEL,SERIAL

• Match on more than the name. Replace VG_NAME and /dev/DEVICE below only after cross-checking size, model, serial number and current mount information.
• Mounted or in use? Stop and resolve that first; do not proceed.
• Already in another VG? That is not spare capacity, whatever the device name looks like. Moving a PV between groups needs a deliberate migration with pvmove and vgreduce; that is outside this guide.

$ sudo pvs -o pv_name,vg_name,pv_size,pv_free /dev/DEVICE
  PV              VG       PSize  PFree
  /dev/DEVICE              100.00g 100.00g

The output format and sizes vary. The important checks are that the path is the intended device and that the VG column is empty for a new PV.

3. Decide whether vgextend should initialise the device

If the device is not yet an LVM PV, vgextend can initialise it as part of the operation. The local manual says this can use PV creation options such as --metadatasize, --pvmetadatacopies, --metadataignore, --dataalignment and --dataalignmentoffset.

That convenience is also a reason to slow down. Initialisation writes an LVM label and may wipe the first four sectors by default: the default for --zero is to wipe those sectors unless --restorefile or --uuid is specified. Never point the command at a disk that might carry a partition table or other data you need.

If the PV was previously missing from this VG and has returned after a transient device failure, use --restoremissing instead: the manual describes this as adding the PV back without re-initialising it. Do not use that option for an unrelated new disk.

4. Preview the operation

Use LVM test mode before the real change. It disables metadata writing, although the command can still produce unusual messages in a multi-stage operation:

$ sudo vgextend --test VG_NAME /dev/DEVICE
  TEST MODE: Metadata will NOT be updated and volumes will not be activated.
  Volume group "VG_NAME" successfully extended

Exact wording depends on the host and the checks that pass. A successful test is useful, but it is not proof that the device identity is correct: read the path again before proceeding. If the command reports a missing device, an existing VG membership or another refusal, fix that cause instead of adding --force.

5. Add the PV

Run the real metadata change with sudo. Include multiple, independently verified PVs as separate arguments when that is genuinely what you want:

$ sudo vgextend --autobackup y VG_NAME /dev/DEVICE
  Physical volume "/dev/DEVICE" successfully created.
  Volume group "VG_NAME" successfully extended

The first line appears when vgextend had to initialise a new PV; an already initialised PV may produce different output. Automatic metadata backup is enabled explicitly here because the manual strongly advises it. LVM normally writes a backup under /etc/lvm/backup/, subject to the host configuration.

Do not treat a zero exit status as permission to start using the extra blocks immediately. The VG has more allocatable space, but existing logical volumes and filesystems have not grown.

6. Verify the new capacity

Confirm both the PV membership and the VG's free space:

$ sudo pvs -o pv_name,vg_name,pv_size,pv_free
$ sudo vgs -o vg_name,pv_count,lv_count,vg_size,vg_free
  VG_NAME  2  3  199.99g  100.00g

Use your own output as the comparison. The new device should appear in pvs with VG_NAME, and the VG's PV count and available size should reflect it. If your next task is to enlarge an LV, stop here and plan that separate change, including filesystem-specific checks and a recovery path.

Recovery and undo

vgextend has no inverse command that safely removes a PV in every situation. If the new PV is unused, inspect the VG first and then use vgreduce as a separate, carefully reviewed operation. If extents have been allocated on it, move them with pvmove before reducing the group. Never delete the PV label or run pvremove while the device is still part of the VG.