The LVM stack.
PV to VG to LV, grown live, with a snapshot.

dbadmin1 needs a growable volume for the database files, mounted at /srv/db, that can be extended without downtime. This is the full LVM stack plus an online resize and a snapshot.

The ticket: now that the disk is partitioned, dbadmin1 needs a volume group named dbvg on /dev/sdb1, a 1GB logical volume named dblv inside it, mounted at /srv/db. The hard requirement is that it must be extensible while mounted, with no downtime. Bonus: take a snapshot before any major migration.

The real problem: LVM is one of the most heavily tested RHCSA topics, and the part people fumble is the two-step resize. Growing the logical volume does not grow the filesystem. You have to do both.

What we are doing: building the full stack, physical volume to volume group to logical volume to mount, then growing it live and taking a snapshot.

The ticket

lsblk    # confirm /dev/sdb1 exists from the partitioning ticket
which pvcreate vgcreate lvcreate    # lvm2 is usually already installed

Concept review. The stack, bottom to top.

man pvcreate vgcreate lvcreate lvextend

LVM is three layers. A physical volume is a disk or partition marked for LVM use. One or more physical volumes are pooled into a volume group, which is just a pool of storage. Out of that pool you carve logical volumes, and a logical volume is the thing you format and mount. The point of all this is that the pool and the volumes can grow after the fact.

[ /dev/sdb1 ]  --pvcreate-->  [ Physical Volume ]
                              --vgcreate-->  [ Volume Group: dbvg ]   (the pool)
                              --lvcreate-->  [ Logical Volume: dblv ]  (what you mount)
                              --mkfs+mount-->  /srv/db

PV   pvcreate   pvs / pvdisplay   pvremove
VG   vgcreate   vgs / vgdisplay   vgremove
LV   lvcreate   lvs / lvdisplay   lvremove

Build the stack

Three commands, bottom to top. Mark the partition as a physical volume, pool it into a volume group, carve a logical volume out of the pool.

sudo pvcreate /dev/sdb1
sudo pvs

sudo vgcreate dbvg /dev/sdb1
sudo vgs

sudo lvcreate -L 1G -n dblv dbvg
sudo lvs

# the LV is reachable at two equivalent paths
ls -l /dev/dbvg/dblv
ls -l /dev/mapper/dbvg-dblv

Sizing flags worth knowing: -L 1G is a fixed size, -l 100%FREE takes all remaining space, and -l 50%VG takes half the pool.

Format and mount

Format XFS and mount it to confirm the stack works. The permanent fstab entry comes in the next ticket.

sudo mkfs.xfs /dev/dbvg/dblv
sudo mkdir -p /srv/db
sudo mount /dev/dbvg/dblv /srv/db
df -h /srv/db

Extend it online, the key skill

This is the part the exam cares about. Growing the logical volume gives it more space, but the filesystem does not know yet. You grow the filesystem separately, and both steps happen live with the volume mounted.

# grow the logical volume by 500MB, instant, no downtime
sudo lvextend -L +500M /dev/dbvg/dblv
sudo lvs dbvg
df -h /srv/db    # df still shows the old size, the FS does not know yet

# grow the XFS filesystem to fill the new space, also live
sudo xfs_growfs /srv/db
df -h /srv/db    # now it shows the new size

Add a second physical volume

When the pool runs low, add more storage to the volume group and then extend the logical volume into it.

sudo pvcreate /dev/sdb3
sudo vgextend dbvg /dev/sdb3
sudo vgs    # VFree grows

# now consume all the free space
sudo lvextend -l +100%FREE /dev/dbvg/dblv
sudo xfs_growfs /srv/db
df -h /srv/db

Snapshot before a migration

A snapshot is a point in time copy you can roll back to. Take one before a risky change, verify it holds the original data, then clean it up.

echo "original DB schema v1" | sudo tee /srv/db/schema.sql

# create the snapshot with -s
sudo lvcreate -L 200M -s -n dblv_snap /dev/dbvg/dblv
sudo lvs    # the snapshot's Attr starts with s

# mount it read-only and confirm the original data
sudo mkdir -p /mnt/db_snapshot
sudo mount -o nouuid,ro /dev/dbvg/dblv_snap /mnt/db_snapshot
cat /mnt/db_snapshot/schema.sql

# simulate a destructive change on the live volume
echo "DROP TABLE users;" | sudo tee /srv/db/schema.sql
cat /mnt/db_snapshot/schema.sql    # snapshot still has the original

# clean up
sudo umount /mnt/db_snapshot
sudo lvremove -y /dev/dbvg/dblv_snap

Exam questions

Write the command first.

Q1. Create a 2GB LV named applv in a new VG called appvg on /dev/sdb1, and format it XFS.

Q2. applv is filling up. Extend it by 1GB online without unmounting, and show every step.

Q3. You added a disk /dev/sdc. Add it to appvg and use all the new space to extend applv.

Answers.

# A1
sudo pvcreate /dev/sdb1
sudo vgcreate appvg /dev/sdb1
sudo lvcreate -L 2G -n applv appvg
sudo mkfs.xfs /dev/appvg/applv
# A2
sudo lvextend -L +1G /dev/appvg/applv
sudo xfs_growfs /mountpoint
# A3
sudo pvcreate /dev/sdc
sudo vgextend appvg /dev/sdc
sudo lvextend -l +100%FREE /dev/appvg/applv
sudo xfs_growfs /mountpoint

Final checklist: confirm everything works

If every check passes, the ticket is done.

# 1. dbvg exists and contains /dev/sdb1
sudo vgs; sudo pvs

# 2. dblv is mounted at /srv/db
df -h /srv/db

# 3. online resize proven (lvextend then xfs_growfs)
# 4. snapshot created and mounted read-only at least once
# 5. all three exam commands written from scratch
# 6. tracker entry checked off

Reply to dbadmin1: dbvg/dblv is mounted at /srv/db. Online resize is verified, lvextend -L +SIZE then xfs_growfs /srv/db. For a pre-migration safety net, lvcreate -L SIZE -s -n NAME /dev/dbvg/dblv.