Study guide

11.3 Assign Physical Volumes to Volume Groups

Red Hat Certified System Administrator RHCSA

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts 1.2 Lab Setup & Performance-Based Study Strategy

2 Essential Tools: Shell, Redirection & Text Analysis

2.1 Shell Prompt and Command Syntax 2.2 Input-Output Redirection and Pipes 2.3 grep and Regular Expressions for Text Analysis

3 Essential Tools: Remote Access, Users & Text Editing

3.1 Access Remote Systems Using SSH 3.2 Log In and Switch Users in Multiuser Targets 3.3 Create and Edit Text Files

4 Essential Tools: Files, Links & Archives

4.1 Create, Delete, Copy, and Move Files and Directories 4.2 Hard and Soft Links 4.3 Archive and Compress with tar, gzip, and bzip2

5 Essential Tools: Permissions & System Documentation

5.1 List, Set, and Change Standard ugo/rwx Permissions 5.2 System Documentation: man, info, and /usr/share/doc

6 Manage Software: RPM and Flatpak

6.1 Configure Access to RPM Repositories 6.2 Install and Remove RPM Software Packages 6.3 Configure Access to Flatpak Repositories 6.4 Install and Remove Flatpak Software Packages

7 Create Simple Shell Scripts

7.1 Conditional Execution: if, test, and [] 7.2 Looping Constructs for Files and Input 7.3 Process Script Inputs ($1, $2, and Beyond) 7.4 Process Shell Command Output in Scripts

8 Operate Running Systems: Boot and Recovery

8.1 Boot, Reboot, and Shut Down a System Normally 8.2 Boot Systems into Different Targets Manually 8.3 Interrupt the Boot Process to Gain Access

9 Operate Running Systems: Processes and Tuning

9.1 Identify and Kill CPU/Memory Intensive Processes 9.2 Adjust Process Scheduling 9.3 Manage Tuning Profiles

10 Operate Running Systems: Logs, Services & File Transfer

10.1 Locate and Interpret System Log Files and Journals 10.2 Preserve System Journals 10.3 Start, Stop, and Check Status of Network Services 10.4 Securely Transfer Files Between Systems

11 Configure Local Storage: Partitions and LVM

11.1 List, Create, and Delete Partitions on GPT Disks 11.2 Create and Remove Physical Volumes 11.3 Assign Physical Volumes to Volume Groups 11.4 Create and Delete Logical Volumes

12 Configure Local Storage: Mounting and Expansion

12.1 Mount File Systems at Boot by UUID or Label 12.2 Add Partitions, Logical Volumes, and Swap Non-Destructively

13 Create and Configure File Systems: Local FS and Permissions

13.1 Create, Mount, and Use VFAT, ext4, and XFS File Systems 13.2 Extend Existing Logical Volumes 13.3 Diagnose and Correct File Permission Problems

14 Create and Configure File Systems: NFS and autofs

14.1 Mount and Unmount Network File Systems Using NFS 14.2 Configure autofs

15 Deploy and Maintain: Scheduling, Services & Targets

15.1 Schedule Tasks with at, cron, and systemd Timers 15.2 Start, Stop, and Enable Services at Boot 15.3 Configure Systems to Boot into a Specific Target

16 Deploy and Maintain: Time, Software Updates & Bootloader

16.1 Configure Time Service Clients 16.2 Install and Update Software from CDN, Remote Repos, and Local Files 16.3 Modify the System Bootloader

17 Manage Basic Networking

17.1 Configure IPv4 and IPv6 Addresses 17.2 Configure Hostname Resolution 17.3 Configure Network Services to Start Automatically at Boot 17.4 Restrict Network Access Using firewalld and firewall-cmd

18 Manage Users and Groups

18.1 Create, Delete, and Modify Local User Accounts 18.2 Change Passwords and Adjust Password Aging 18.3 Create, Delete, and Modify Local Groups and Memberships 18.4 Configure Privileged Access

19 Manage Security: Firewall, umask & SSH Keys

19.1 Configure Firewall Settings with firewall-cmd and firewalld 19.2 Manage Default File Permissions 19.3 Configure Key-Based Authentication for SSH

20 Manage Security: SELinux Modes and Contexts

20.1 Set Enforcing and Permissive Modes for SELinux 20.2 List and Identify SELinux File and Process Contexts 20.3 Restore Default File Contexts

21 Manage Security: SELinux Ports and Booleans

21.1 Manage SELinux Port Labels 21.2 Use Boolean Settings to Modify SELinux Settings

11.3 Assign Physical Volumes to Volume Groups

Key Takeaways Explain This Topic AI

Create a volume group with vgcreate VGNAME PV [PV...]; add capacity later with vgextend; remove a PV from a VG with vgreduce.

Inspect with vgs and vgdisplay: VSize/VFree (or size/free) show capacity available for new logical volumes.

A VG pools one or more PVs into a single allocation space; PE (physical extent) size is set at vgcreate time (default often 4 MiB).

Never vgreduce away a PV that still holds extents without pvmove or freeing LVs; exam layouts usually make reduce straightforward when asked.

VG metadata is persistent on its PVs; after reboot, VGs activate with the LVM stack—verify with vgs that names and free space match the task.

Last updated: August 2026

11.3 Assign Physical Volumes to Volume Groups

Quick Answer: Build a pool with vgcreate myvg /dev/sdb1 . Grow it with vgextend myvg /dev/sdc1 . Shrink membership with vgreduce myvg /dev/sdc1 . Check vgs / vgdisplay for size and free space. The VG name you choose becomes part of later LV paths like /dev/myvg/data and /dev/mapper/myvg-data .

Official skill focus

EX200 Configure local storage includes assigning physical volumes to volume groups . In plain language: take one or more PVs and combine them into a named pool of extents from which you create logical volumes.

Typical tasks:

  • “Create a volume group named research using /dev/sdb1 .”
  • “Add /dev/sdc1 to volume group research .”
  • “Remove /dev/sdd1 from research .”
  • Create a volume group: vgcreate sudo vgcreate research /dev/sdb1
  • sudo vgcreate research /dev/sdb1 /dev/sdc1 # multi-PV from the start
  • sudo vgcreate -s 16M research /dev/sdb1 # custom PE size (advanced; default usually OK)

Rules of thumb:

VG name must be unique on the system ( rhel or rl may already exist for root).

Arguments after the name are PVs (devices already pvcreate ’d).

Do not use a PV that already belongs to another VG.

  • Verify: sudo vgs
  • sudo vgdisplay research
  • sudo pvs
  • # /dev/sdb1 should now show VG research
  • Reading vgs VG #PV #LV #SN Attr VSize VFree
  • research 1 0 0 wz--n- 20.00g 20.00g
  • rhel 1 2 0 wz--n- <39.00g <3.00g
  • Field Meaning
  • VG Volume group name
  • #PV / #LV Counts of physical and logical volumes
  • VSize Total VG capacity
  • VFree Free space for new or extended LVs

If the task only creates a VG, #LV may be 0 and VFree ≈ VSize. That is success.

  • Extend a volume group: vgextend
  • When you need more pool capacity: sudo pvcreate /dev/sdc1 # if not already a PV
  • sudo vgextend research /dev/sdc1
  • sudo vgs research
  • sudo pvs

vgextend is the day-2 operation matching “add this disk to the existing VG.” It does not automatically grow filesystems; it only adds free extents to the VG. Growing an LV/filesystem is a separate skill (often lvextend + xfs_growfs in a later objective).

Reduce a volume group: vgreduce sudo vgreduce research /dev/sdc1

Preconditions:

No allocated extents remaining on that PV (or LVM cannot release it).

If allocations exist, move them: sudo pvmove /dev/sdc1 (needs free space on other PVs in the VG), then vgreduce . sudo pvs -o+pv_used,pv_free

  • sudo pvmove /dev/sdc1
  • sudo vgreduce research /dev/sdc1
  • sudo pvremove /dev/sdc1 # only if task also wants PV removed
  • Empty VG removal (if task says delete the VG entirely—adjacent skill): sudo lvremove ... # remove LVs first
  • sudo vgremove research

Focus this section on assign/extend/reduce membership; full teardown order is good hygiene for labs.

Physical extents (PE) — enough theory for the exam

A VG chops PV space into physical extents (default commonly 4 MiB ). Logical volumes are allocated in whole extents. Practical implications:

Requested LV sizes round to extent boundaries.

vgs free space is what you can still allocate.

Custom -s at vgcreate is rarely required unless a task specifies extent size. sudo vgdisplay research | egrep 'PE Size|Total PE|Free PE|VG Size'

Naming and device paths

  • Object Example
  • VG name research
  • Later LV research/data
  • Kernel DM node /dev/mapper/research-data
  • Convenience symlink /dev/research/data

Hyphens in VG or LV names are doubled in mapper paths (LVM escaping). Prefer simple names ( data , vgdata , research ) on the exam to avoid confusion.

Do not confuse:

  • /dev/sdb1 — PV
  • research — VG (not a block device you mkfs directly)
  • /dev/mapper/research-data — LV (after lvcreate)
  • Non-destructive exam mindset

List existing VGs first: sudo vgs — avoid clashing with rhel / rl root VG.

Only consume free PVs shown by pvs with empty or intended VG fields.

Prefer adding a new VG for lab tasks rather than extending the system VG unless the task says so.

Extending the root VG is allowed when asked (“add free space on /dev/sdb1 to rhel ”)—still double-check the name. sudo vgs

  • sudo pvs
  • # Task: add /dev/sdb1 to existing VG rhel
  • sudo vgextend rhel /dev/sdb1
  • sudo vgs rhel
  • Activation awareness
  • Normally VGs activate at boot via systemd/LVM generators. Manual tools: sudo vgchange -ay
  • sudo vgchange -ay research
  • sudo vgchange -an research # deactivate (no open LVs)

If vgs shows the VG but LVs are missing under /dev/mapper , check activation and lvscan . Cold exam images almost always auto-activate local VGs.

  • End-to-end exam scenarios
  • Scenario A — New VG from one PV
  • Task: Create VG tools on /dev/vdb1 . sudo pvs | grep vdb1
  • sudo vgcreate tools /dev/vdb1
  • sudo vgs tools
  • # VFree should approximately equal PV size (minus tiny metadata overhead)
  • Scenario B — Multi-PV VG
  • Task: Create backupvg using /dev/sdb1 and /dev/sdc1 . sudo pvcreate /dev/sdb1 /dev/sdc1 # if needed
  • sudo vgcreate backupvg /dev/sdb1 /dev/sdc1
  • sudo vgs backupvg
  • # #PV should be 2; VSize ≈ sum of PVs
  • Scenario C — Extend existing VG
  • Task: Add /dev/sdd1 to backupvg . sudo pvcreate /dev/sdd1
  • sudo vgextend backupvg /dev/sdd1
  • sudo pvs
  • sudo vgs backupvg
  • Scenario D — Reduce PV out of VG
  • Task: Remove /dev/sdd1 from backupvg (assume no LVs use it, or free). sudo vgreduce backupvg /dev/sdd1
  • sudo pvs # sdd1 free or only PV without VG
  • Verification checklist
  • Check Command
  • VG exists with correct name vgs / vgdisplay NAME
  • Correct PVs inside pvs or vgdisplay -v
  • Free space available for LVs vgs -o+vg_free
  • Survives reboot reboot lab → vgs again
  • Sample verbose membership: sudo vgdisplay -v research
  • Persistence and scoring

VG metadata is stored in LVM headers on member PVs. After vgcreate / vgextend / vgreduce , changes persist across reboot without editing /etc/fstab . Graders look for the named VG , membership, and free size—not whether you also mounted a filesystem (unless the combined task requires it).

If you create a VG but never create an LV, that is fine when the objective stops at VG assignment. Do not leave partial wrong names ( Research vs research —use the exact case requested).

Common traps

vgcreate with a partition that is not a PV — run pvcreate first.

Name collision with existing VG.

vgextend on a device still containing a filesystem signature but not pvcreate’d — initialize PV properly.

vgreduce while extents remain — pvmove or delete/move LVs first.

Extending root VG by accident when a new VG was required (or the reverse).

Thinking vgextend grows / automatically — it only adds free PE; LV+FS extend is separate.

Typos in VG name propagating into later lvcreate -n paths.

Coordination with surrounding skills

Before: GPT partitions + pvcreate (11.1–11.2).

After: lvcreate / lvremove (11.4), then filesystems, fstab, and non-destructive growth objectives in the next chapter.

Swap/LV on VG: still needs lvcreate then mkswap / swapon or filesystem tools.

Section checkpoint

You should create volume groups with vgcreate , expand them with vgextend , remove PVs with vgreduce , verify pool size and membership with vgs / vgdisplay / pvs , protect the system VG unless tasked otherwise, and understand that VG changes persist on disk for reboot. That is the EX200 standard for assigning physical volumes to volume groups.