LFCS 84 🐧 LVM — Volume Groups - KandZ

⏱️ Estimated read: 12 min | |

A Volume Group is the pool in the middle of the LVM stack. It sits between the Physical Volumes that provide raw capacity and the Logical Volumes that consume it. The VG aggregates the capacity of its member PVs into a single address space, and the administrator allocates LVs from that address space without knowing which physical device the extents come from. The VG is also where the extent size is decided, the metadata is managed, and the group’s identity is established.

This chapter covers the Volume Group layer: creating, inspecting, extending, reducing, and modifying a VG. It assumes the conceptual model from LFCS 82—PV, VG, LV, and PE—and the Physical Volume operations from LFCS 83. It focuses on the commands and the failure modes that the LFCS exam tests: how to extend a VG with a new disk, how to safely remove a PV from a VG, and how to recover a VG that has lost a member.

Key point: The Volume Group is the unit of allocation, not the unit of storage. It does not move data. It records which Physical Volumes belong to the pool and how many Physical Extents are free. The data lives on the PVs, and the VG’s metadata is the map that connects them.

Why the Volume Group layer exists

The aggregation boundary. A Physical Volume is a single device. A Logical Volume may need to span multiple devices, or the administrator may want to add capacity without recreating the LVs. The VG is the aggregation layer: it pools the PVs, so the LVs are allocated from the pool rather than from a specific device . This is the layer that decouples the logical block device from the physical device’s boundaries.

The extent size decision. The Physical Extent size is set when the VG is created and cannot be changed afterward. The default is 4 MiB, and it is a trade-off: smaller extents allow finer allocation granularity but require more metadata; larger extents reduce metadata overhead but waste space on small LVs . The VG is the container for this decision, which is why the vgcreate command takes the -s option.

The metadata management. The VG’s configuration—which PVs it contains, which LVs it has, and how the LEs map to PEs—is stored as metadata on each PV. The VG is the unit that the metadata describes, and the metadata copies on the PVs are the redundancy mechanism for recovering from a corrupted disk . The vgcfgbackup and vgcfgrestore commands operate on the VG’s metadata, not on the data.

The identity. The VG has a name and a UUID. The name is what the administrator uses in commands and what appears in the LV device path (/dev/vg_name/lv_name). The UUID is what LVM uses internally to identify the VG even if the name is changed. Both are established at creation and are the VG’s identity in the system.

a. Creating and inspecting a Volume Group

vgcreate takes a VG name and one or more PVs. The PVs must already be initialized with pvcreate. The command assigns the PVs to the new VG and writes the VG metadata to each PV. The -s option sets the Physical Extent size, and the -v flag adds verbose output.

# Create a Volume Group named vg_data from two PVs.
# The default PE size is 4 MiB.
sudo vgcreate vg_data /dev/sdc /dev/sdd

# Create a VG with a 16 MiB PE size.
sudo vgcreate -s 16M vg_big /dev/sde

vgs provides a compact report of all VGs. The columns show the VG name, the number of PVs, the number of LVs, the number of snapshots, the attributes, the total size, and the free space .

# Compact report of all Volume Groups.
sudo vgs

# Example output:
#   VG      #PV #LV #SN Attr   VSize   VFree
#   vg_data   2   1   0 wz--n-  19.99g  9.99g

vgdisplay provides the detailed view. It shows the VG’s UUID, size, PE size, total and free PE count, and the list of member PVs. The -s flag produces a short format similar to vgs .

# Detailed attributes of a specific Volume Group.
sudo vgdisplay vg_data

vgscan scans all block devices for LVM metadata and rebuilds the VG configuration cache. It is the recovery tool for a system that has lost its LVM configuration, such as after a disk is moved from another machine .

# Scan for Volume Groups and rebuild the cache.
sudo vgscan

b. Extending and reducing a Volume Group

vgextend adds a PV to an existing VG. The PV must be initialized with pvcreate and must not already belong to another VG. The VG’s size grows by the size of the new PV, and the new extents become available for allocation.

# Add /dev/sde to the vg_data Volume Group.
sudo vgextend vg_data /dev/sde

# Verify the new size.
sudo vgs vg_data

vgreduce removes a PV from a VG. The PV must have no allocated extents, which means the LVs that used it must be moved first with pvmove. The command fails if the PV still has extents, and it fails if the removal would leave the VG without enough PVs to hold the existing LVs.

# Move the extents off /dev/sdc.
sudo pvmove /dev/sdc

# Remove /dev/sdc from the VG.
sudo vgreduce vg_data /dev/sdc

The --removemissing option is the recovery path for a VG that has lost a PV. If a disk fails and is removed from the system, the VG’s metadata still records it as a member. vgreduce --removemissing vg_name removes the missing PV from the metadata and, if possible, recovers the LVs that did not have extents on the missing disk. This is a data-loss scenario if the missing PV had extents that were not mirrored, but it is the only way to bring the VG back to a consistent state.

# Remove a missing PV from the VG metadata.
sudo vgreduce --removemissing vg_data

c. Modifying and recovering a Volume Group

vgchange changes the attributes of a VG. The -a y option activates the VG’s LVs, which is necessary after a boot or after a VG is imported. The -a n option deactivates them. The -x n option disables allocation of new extents on the VG, which is useful when the VG is being prepared for removal or when the underlying storage is failing.

# Activate all LVs in the VG.
sudo vgchange -a y vg_data

# Deactivate all LVs in the VG.
sudo vgchange -a n vg_data

# Disable new allocations on the VG.
sudo vgchange -x n vg_data

vgrename changes the VG’s name. The LVs’ device paths change accordingly, and any fstab or application configuration that references the old path must be updated. The VG’s UUID does not change, so the internal identity is preserved.

# Rename the VG. The LVs become /dev/vg_new/lv_name.
sudo vgrename vg_data vg_new

vgcfgbackup and vgcfgrestore are the metadata backup and restore tools. The backup writes the VG’s configuration to a text file in /etc/lvm/backup/. The restore reads the file and rewrites the metadata on the PVs. The restore is the recovery path for a VG whose metadata has been corrupted .

# Back up the VG metadata.
sudo vgcfgbackup vg_data

# Restore the VG metadata from the backup.
sudo vgcfgrestore vg_data

vgsplit and vgmerge move PVs between VGs. The split creates a new VG from a subset of the PVs, and the merge combines two VGs. These are less common in the LFCS exam, but they are the commands for reorganizing the VG structure without recreating the LVs.

Complete Example Session

# ============================================
# PART 1: THE STARTING STATE
# ============================================
# The PVs are initialized and ready to be pooled.

sudo pvs

# ============================================
# PART 2: CREATE THE VG
# ============================================
# Pool the PVs into a single address space.

sudo vgcreate vg_data /dev/sdc /dev/sdd

# ============================================
# PART 3: VERIFY WITH vgs
# ============================================
# The VG is listed with its size and free space.

sudo vgs

# ============================================
# PART 4: VERIFY WITH vgdisplay
# ============================================
# Detailed attributes: UUID, PE size, PV list.

sudo vgdisplay vg_data

# ============================================
# PART 5: CREATE AN LV
# ============================================
# The LV consumes extents from the VG pool.

sudo lvcreate -n lv_app -L 5G vg_data

# ============================================
# PART 6: EXTEND THE VG
# ============================================
# Add a new PV to the VG.

sudo pvcreate /dev/sde
sudo vgextend vg_data /dev/sde
sudo vgs vg_data

# ============================================
# PART 7: REDUCE THE VG
# ============================================
# Move extents off the PV, then remove it.

sudo pvmove /dev/sdc
sudo vgreduce vg_data /dev/sdc

# ============================================
# PART 8: THE MISSING PV CASE
# ============================================
# If a PV is removed from the system without pvmove,
# the VG metadata still records it.

# sudo vgreduce --removemissing vg_data
# This removes the missing PV from the metadata.

# ============================================
# PART 9: THE METADATA BACKUP
# ============================================
# Back up the VG configuration.

sudo vgcfgbackup vg_data
ls /etc/lvm/backup/

# ============================================
# PART 10: THE FULL PICTURE
# ============================================
# vgcreate pools the PVs.
# vgextend adds capacity.
# vgreduce removes a PV (after pvmove).
# vgchange activates or deactivates.
# vgcfgbackup and vgcfgrestore manage metadata.

echo "VG workflow complete."

The ten parts walk through the full lifecycle: create, inspect, use, extend, reduce, handle the missing case, and back up the metadata. The sequence is the same regardless of whether the VG is used for a database, a virtual machine store, or a container host.

Quick Reference

VG Commands

Command	Purpose
`vgcreate`	Create a VG from PVs
`vgs`	Compact report of all VGs
`vgdisplay`	Detailed attributes
`vgscan`	Scan for VGs, rebuild cache
`vgextend`	Add a PV to a VG
`vgreduce`	Remove a PV from a VG
`vgchange`	Modify VG attributes
`vgrename`	Rename a VG
`vgcfgbackup`	Back up VG metadata
`vgcfgrestore`	Restore VG metadata

Creation Options

Option	Effect
`-s SIZE`	Set PE size
`-v`	Verbose output
`-n NAME`	Set VG name (rarely used)

vgs Output

Column	Meaning
`VG`	Volume Group name
`#PV`	Number of Physical Volumes
`#LV`	Number of Logical Volumes
`#SN`	Number of snapshots
`VSize`	Total size
`VFree`	Free space

Recovery Commands

Situation	Command
Disk failed, PV missing	`vgreduce --removemissing`
Metadata corrupted	`vgcfgrestore`
Cache lost after disk move	`vgscan`
VG needs activation	`vgchange -a y`

Best Practices

✅ Do This:

# Create the VG from initialized PVs.
sudo vgcreate vg_data /dev/sdc /dev/sdd                          // ✅

# Verify with vgs and vgdisplay.
sudo vgs vg_data                                                  // ✅

# Extend with a new PV.
sudo vgextend vg_data /dev/sde                                    // ✅

# Move extents before removing a PV.
sudo pvmove /dev/sdc                                              // ✅

# Back up metadata before changes.
sudo vgcfgbackup vg_data                                          // ✅

❌ Don’t Do This:

# Don't vgreduce a PV that still has extents.
sudo vgreduce vg_data /dev/sdc  # fails                           // ❌

# Don't vgcreate without initializing the PVs.
sudo vgcreate vg_data /dev/sdc  # needs pvcreate first            // ❌

# Don't change the PE size after creation.
# The PE size is fixed at VG creation.                            // ❌

Common Pitfalls

Pitfall	Why It Happens	Fix
`vgcreate` fails	PV not initialized	`pvcreate` first
`vgextend` fails	PV belongs to another VG	`vgreduce` from the other VG first
`vgreduce` fails	PV still has extents	`pvmove` first
VG missing after disk move	Cache not updated	`vgscan`
Metadata corrupted	Disk failure or power loss	`vgcfgrestore` from backup
Cannot activate VG	VG not activated after boot	`vgchange -a y`

Real-World Examples

1. Create VG

sudo vgcreate vg_data /dev/sdc /dev/sdd

2. Compact Report

sudo vgs

3. Detailed Report

sudo vgdisplay vg_data

4. Extend VG

sudo vgextend vg_data /dev/sde

5. Reduce VG

sudo vgreduce vg_data /dev/sdc

6. Activate VG

sudo vgchange -a y vg_data

7. Rename VG

sudo vgrename vg_data vg_new

8. Backup Metadata

sudo vgcfgbackup vg_data

9. Restore Metadata

sudo vgcfgrestore vg_data

10. Remove Missing PV

sudo vgreduce --removemissing vg_data

Visual

The VG in the LVM Stack

┌─────────────────────────────────────────────────────────┐
│  LOGICAL VOLUMES                                        │
│  lv_app, lv_data, lv_home                               │
│         │                                               │
│         ▼                                               │
│  VOLUME GROUP vg_data                                   │
│  ┌───────────────────────────────────────────────────┐  │
│  │  Pool of Physical Extents                         │  │
│  │  (allocated to LVs on demand)                     │  │
│  └───────────────────────────────────────────────────┘  │
│         │                                               │
│         ▼                                               │
│  PHYSICAL VOLUMES                                       │
│  /dev/sdc, /dev/sdd, /dev/sde                           │
└─────────────────────────────────────────────────────────┘

vgextend and vgreduce

┌─────────────────────────────────────────────────────────┐
│  BEFORE                                                 │
│  vg_data: 20 GB (2 PVs), 5 GB allocated, 15 GB free     │
│                                                         │
│  vgextend vg_data /dev/sde                              │
│         │                                               │
│         ▼                                               │
│  AFTER                                                  │
│  vg_data: 30 GB (3 PVs), 5 GB allocated, 25 GB free     │
│                                                         │
│  ─────────────────────────────────────────────────────  │
│                                                         │
│  vgreduce requires pvmove first.                        │
│  pvmove /dev/sdc → extents moved                        │
│  vgreduce vg_data /dev/sdc → PV removed                 │
└─────────────────────────────────────────────────────────┘

The Missing PV Recovery

┌─────────────────────────────────────────────────────────┐
│  NORMAL STATE                                           │
│  vg_data contains: /dev/sdc, /dev/sdd                   │
│                                                         │
│  DISK FAILURE                                           │
│  /dev/sdc is removed from the system                    │
│         │                                               │
│         ▼                                               │
│  VG METADATA still records /dev/sdc as a member         │
│  LVM commands report the VG as incomplete               │
│         │                                               │
│         ▼  vgreduce --removemissing vg_data             │
│  METADATA UPDATED                                       │
│  /dev/sdc removed from the VG record                    │
│  LVs that had extents on sdc are lost (data loss)       │
└─────────────────────────────────────────────────────────┘

The Metadata Backup

┌─────────────────────────────────────────────────────────┐
│  /etc/lvm/backup/vg_data                                │
│  ┌───────────────────────────────────────────────────┐  │
│  │  vg_data {                                        │  │
│  │      id = "..."                                   │  │
│  │      seqno = 5                                    │  │
│  │      physical_volumes {                           │  │
│  │          /dev/sdc { ... }                         │  │
│  │          /dev/sdd { ... }                         │  │
│  │      }                                            │  │
│  │      logical_volumes {                            │  │
│  │          lv_app { ... }                           │  │
│  │      }                                            │  │
│  │  }                                                │  │
│  └───────────────────────────────────────────────────┘  │
│                                                         │
│  vgcfgrestore reads this file and rewrites the metadata │
│  on the PVs.                                            │
└─────────────────────────────────────────────────────────┘

Summary

Item	Value
Purpose	Pool of Physical Volumes
Create	`vgcreate vg_name /dev/sdX ...`
Compact report	`vgs`
Detailed report	`vgdisplay`
Scan and cache	`vgscan`
Add a PV	`vgextend vg_name /dev/sdX`
Remove a PV	`vgreduce vg_name /dev/sdX`
Activate	`vgchange -a y vg_name`
Rename	`vgrename old new`
Backup metadata	`vgcfgbackup vg_name`
Restore metadata	`vgcfgrestore vg_name`

Key takeaways:

The VG is the aggregation layer. It pools the PVs and allocates the LVs from the pool. The administrator manages the VG, not the individual PVs, for capacity decisions .
The PE size is set at VG creation. It cannot be changed afterward. The -s option on vgcreate is the only place to choose it .
vgextend adds capacity; vgreduce removes a PV. The latter requires the PV to be empty, which means pvmove first .
vgreduce --removemissing is the failure recovery path. When a PV is lost, the metadata still records it. The --removemissing flag removes it from the record and, if possible, recovers the LVs that did not depend on it .
vgcfgbackup and vgcfgrestore are the metadata tools. The backup is a text file in /etc/lvm/backup/. The restore rewrites the metadata on the PVs, which is the recovery path for a corrupted VG .
vgscan rebuilds the cache. When a VG is not recognized after a disk is moved, vgscan finds the metadata and updates the LVM cache.

Remember: The Volume Group is the layer where the administrator’s decisions about capacity live. The PVs are the raw devices, and the LVs are the block devices that the filesystems use, but the VG is the pool that connects them. The vgcreate command establishes the pool, the extent size, and the identity. The vgextend and vgreduce commands adjust the pool’s membership. The vgchange and vgcfgbackup commands manage the pool’s state and its metadata. The commands are simple; the discipline is the order—pvmove before vgreduce, backup before changes, and --removemissing only when the alternative is a system that will not start.

Was this helpful?

Stop using slow, ad-bloated tool sites! 🤮

🔎 Search “KandZ Tools” on Google to use many professional utilities for free.

KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)

⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free

🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!