LVM in Linux: PV, VG and LV from start to finish

Everything here runs on rocky01 as student with sudo. You’ll build the real lab storage on sdb, which later lessons use, and a throwaway stack on sdc3 that you remove again at the end. Leave sdc1 and sdc2 alone: they hold /srv/data1 and /srv/data2 from Lesson 43.

Before you start, run lsblk and make sure you know which disk is which: the 20 GB disk with partitions is the OS, and you never touch it in this lesson.

1Look at the LVM the installer already built

Run this:

lsblk
sudo pvs
sudo vgs
sudo lvs

You should see something like this:

NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sda           8:0    0   20G  0 disk
├─sda1        8:1    0  600M  0 part /boot/efi
├─sda2        8:2    0    1G  0 part /boot
└─sda3        8:3    0 18.4G  0 part
  ├─rl-root 253:0    0 16.4G  0 lvm  /
  └─rl-swap 253:1    0    2G  0 lvm  [SWAP]
sdb           8:16   0    5G  0 disk
sdc           8:32   0    5G  0 disk
├─sdc1        8:33   0    2G  0 part /srv/data1
├─sdc2        8:34   0    2G  0 part /srv/data2
└─sdc3        8:35   0 1023M  0 part
sr0          11:0    1 1024M  0 rom  

  PV         VG Fmt  Attr PSize  PFree
  /dev/sda3  rl lvm2 a--  18.41g    0
  VG #PV #LV #SN Attr   VSize  VFree
  rl   1   2   0 wz--n- 18.41g    0
  LV   VG Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  root rl -wi-ao---- 16.41g
  swap rl -wi-ao----  2.00g

The installer made sda3 a PV, put it in the VG rl and cut two LVs from it, root (16.41g) and swap (2.00g), with no free space left (VFree 0). In lsblk you see them as rl-root and rl-swap under sda3, with major number 253, which is device-mapper. sdb is the empty 5 GB disk from Lesson 42, and sdc carries the three partitions from Lessons 42 and 43: two mounted file systems and sdc3, which is no longer used as swap.

The Attr column is a row of flags. For an LV, -wi-ao---- means: normal volume (first dash), writable, inherit allocation, active (a) and open (o), which here means mounted or in use as swap.

✅ Checkpoint: You can name the OS volume group (rl), its two LVs, the empty disk sdb and the partitions on sdc.

2Make sure sdb is empty

Run this:

lsblk -f /dev/sdb
sudo wipefs /dev/sdb

You should see something like this:

NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
sdb                                                    

No FSTYPE, no UUID, and wipefs printed nothing, which means it found no file system, RAID or LVM signature on sdb. wipefs without options only reads; it changes the disk only when you add -a.

If sdb shows a signature, you used it for practice earlier. Clear it with sudo wipefs -a /dev/sdb only after checking with lsblk -f and findmnt that nothing on it is mounted. Check the device name twice before you press Enter.

✅ Checkpoint: lsblk -f shows no FSTYPE on sdb, and wipefs prints nothing.

3Turn sdb into a physical volume

Run this:

sudo pvcreate /dev/sdb
sudo pvs

You should see something like this:

  Physical volume "/dev/sdb" successfully created.
  PV         VG Fmt  Attr PSize  PFree
  /dev/sda3  rl lvm2 a--  18.41g    0
  /dev/sdb      lvm2 ---   5.00g 5.00g

sdb is now a PV with no VG yet, so the VG column is empty and Attr shows --- (not allocatable until it joins a VG). On Rocky 10, pvcreate also added sdb to the LVM devices file. Check it:

sudo lvmdevices | grep -o 'DEVNAME=[^ ]*'

You should see something like this:

DEVNAME=/dev/sda3
DEVNAME=/dev/sdb

On Ubuntu the devices file is off by default, so this step is skipped there; sudo lvmconfig --typeconfig full devices/use_devicesfile tells you which mode a server uses.

✅ Checkpoint: pvs lists /dev/sdb with Fmt lvm2 and PSize 5.00g.

4Create the volume group vg_data

Run this:

sudo vgcreate vg_data /dev/sdb
sudo vgs
sudo vgdisplay vg_data | grep -E 'PE Size|Total PE|Free  PE'

You should see something like this:

  Volume group "vg_data" successfully created
  VG      #PV #LV #SN Attr   VSize  VFree
  rl        1   2   0 wz--n- 18.41g     0
  vg_data   1   0   0 wz--n- <5.00g <5.00g
  PE Size               4.00 MiB
  Total PE              1279
  Free  PE / Size       1279 / <5.00 GiB

vg_data has one PV and no LVs yet. The size shows as <5.00g because 1279 extents of 4 MiB is 5116 MiB: the first MiB of the disk holds the label and metadata, and the last 3 MiB don't make a whole extent. VG Attr wz–n- means writable, resizable, normal allocation.

✅ Checkpoint: vgs shows vg_data with #PV 1 and VFree <5.00g, and PE Size is 4.00 MiB.

5Cut out lv_app and lv_logs

Run this:

sudo lvcreate -n lv_app -L 2G vg_data
sudo lvcreate -n lv_logs -l 256 vg_data
sudo lvs vg_data
sudo vgs vg_data

You should see something like this:

  Logical volume "lv_app" created.
  Logical volume "lv_logs" created.
  LV      VG      Attr       LSize Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  lv_app  vg_data -wi-a----- 2.00g
  lv_logs vg_data -wi-a----- 1.00g
  VG      #PV #LV #SN Attr   VSize  VFree
  vg_data   1   2   0 wz--n- <5.00g <2.00g

lv_app was sized in gigabytes with -L 2G, and lv_logs in extents with -l 256 (256 x 4 MiB = 1 GiB). Both are active (a) but not open yet, because nothing is mounted. Almost 2 GiB stays free in the VG, on purpose.

Now look at the device names and the extent map:

ls -l /dev/vg_data/lv_app /dev/vg_data/lv_logs
sudo lvs -o lv_name,lv_size,seg_le_ranges vg_data

You should see something like this:

lrwxrwxrwx. 1 root root 7 Oct 27 11:20 /dev/vg_data/lv_app -> ../dm-2
lrwxrwxrwx. 1 root root 7 Oct 27 11:20 /dev/vg_data/lv_logs -> ../dm-3
  LV      LSize LE Ranges
  lv_app  2.00g /dev/sdb:0-511
  lv_logs 1.00g /dev/sdb:512-767

The friendly names are symlinks to dm-2 and dm-3, and the map shows lv_app on extents 0 to 511 of sdb and lv_logs on 512 to 767.

Try it yourself: build the whole new-disk-to-mounted-LV sequence in the Command Builder.

✅ Checkpoint: lvs shows lv_app 2.00g and lv_logs 1.00g in vg_data, and vgs shows VFree <2.00g.

6Put XFS and ext4 on the volumes

Run this:

sudo mkfs.xfs /dev/vg_data/lv_app
sudo mkfs.ext4 /dev/vg_data/lv_logs

You should see something like this (mkfs.xfs output shortened):

meta-data=/dev/vg_data/lv_app    isize=512    agcount=4, agsize=131072 blks
         =                       sectsz=512   attr=2, projid32bit=1
...
data     =                       bsize=4096   blocks=524288, imaxpct=25
...
log      =internal log           bsize=4096   blocks=16384, version=2

mke2fs 1.47.1 (20-May-2024)
Creating filesystem with 262144 4k blocks and 65536 inodes
Filesystem UUID: c2d84a17-5e3b-4f0a-9b6e-71a3d8f0e245
Superblock backups stored on blocks:
	32768, 98304, 163840, 229376

Allocating group tables: done
Writing inode tables: done
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done

XFS split the 2 GiB volume into 4 allocation groups of 131072 blocks (4 KiB each), and ext4 made 262144 blocks with a journal. XFS is Rocky’s default and grows online but can never shrink; ext4 grows online and can shrink offline. You’ll use both facts in Lesson 45.

✅ Checkpoint: Both commands finish without an error, and ext4 prints its Filesystem UUID.

7Mount both volumes by UUID

Run this:

sudo mkdir -p /srv/app /srv/logs
sudo blkid /dev/vg_data/lv_app /dev/vg_data/lv_logs

You should see something like this:

/dev/mapper/vg_data-lv_app: UUID="6b1f3c2e-9a4d-4e57-8c1b-2f7d0a9e5c31" BLOCK_SIZE="512" TYPE="xfs"
/dev/mapper/vg_data-lv_logs: UUID="c2d84a17-5e3b-4f0a-9b6e-71a3d8f0e245" BLOCK_SIZE="4096" TYPE="ext4"

Paste this whole block (it adds two lines to fstab, reloads systemd and mounts everything):

echo "UUID=$(sudo blkid -s UUID -o value /dev/vg_data/lv_app) /srv/app xfs defaults 0 0" | sudo tee -a /etc/fstab
echo "UUID=$(sudo blkid -s UUID -o value /dev/vg_data/lv_logs) /srv/logs ext4 defaults 0 2" | sudo tee -a /etc/fstab
sudo systemctl daemon-reload
sudo mount -a
findmnt -o TARGET,SOURCE,FSTYPE /srv/app
findmnt -n -o TARGET,SOURCE,FSTYPE /srv/logs
df -h /srv/app /srv/logs

You should see something like this:

UUID=6b1f3c2e-9a4d-4e57-8c1b-2f7d0a9e5c31 /srv/app xfs defaults 0 0
UUID=c2d84a17-5e3b-4f0a-9b6e-71a3d8f0e245 /srv/logs ext4 defaults 0 2
TARGET    SOURCE                      FSTYPE
/srv/app  /dev/mapper/vg_data-lv_app  xfs
/srv/logs /dev/mapper/vg_data-lv_logs ext4
Filesystem                   Size  Used Avail Use% Mounted on
/dev/mapper/vg_data-lv_app   2.0G   71M  1.9G   4% /srv/app
/dev/mapper/vg_data-lv_logs  974M   24K  907M   1% /srv/logs

tee echoes the two lines it appended, and findmnt and df confirm both mounts. The last field is the fsck pass: 0 for XFS (it has its own repair tool and doesn’t use boot-time fsck) and 2 for ext4. The ext4 size shows as 974M because some space goes to inode tables and the journal, and Avail is lower again because 5 percent is reserved for root.

You could also write /dev/mapper/vg_data-lv_app in fstab, because LVM names don’t change between boots the way sdb and sdc can. Most teams use UUID anyway so every line in the file follows one rule.

✅ Checkpoint: df shows /srv/app at 2.0G (XFS) and /srv/logs at 974M (ext4).

8Reboot and prove the mounts come back

Check fstab, then reboot:

sudo findmnt --verify
sudo systemctl reboot

Log in again and run:

sudo lvs
df -h /srv/app /srv/logs

You should see something like this:

Success, no errors or warnings detected
  LV      VG      Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  lv_app  vg_data -wi-ao----  2.00g
  lv_logs vg_data -wi-ao----  1.00g
  root    rl      -wi-ao---- 16.41g
  swap    rl      -wi-ao----  2.00g
Filesystem                   Size  Used Avail Use% Mounted on
/dev/mapper/vg_data-lv_app   2.0G   71M  1.9G   4% /srv/app
/dev/mapper/vg_data-lv_logs  974M   24K  907M   1% /srv/logs

findmnt checked every fstab line before you rebooted (Lesson 43). After the boot, LVM activated vg_data on its own and systemd mounted both file systems from fstab, so the two LVs show -wi-ao---- like the OS volumes. lvs sorts by VG name, which is why rl’s volumes come after vg_data’s here.

✅ Checkpoint: After the reboot, both /srv/app and /srv/logs are mounted without you doing anything.

9Practise the whole lifecycle on sdc3

Check sdc3 isn’t in use as swap (the command prints nothing for it), then clear its old swap signature and build a throwaway stack (paste this whole block):

swapon --show | grep sdc3
sudo wipefs -a /dev/sdc3
sudo pvcreate /dev/sdc3
sudo vgcreate vg_test /dev/sdc3
sudo lvcreate -n lv_tmp -l 100%FREE vg_test
sudo mkfs.xfs -q /dev/vg_test/lv_tmp
sudo mkdir -p /mnt/tmp
sudo mount /dev/vg_test/lv_tmp /mnt/tmp
echo "hello from vg_test" | sudo tee /mnt/tmp/note.txt
sudo lvs vg_test

You should see something like this:

/dev/sdc3: 10 bytes were erased at offset 0x00000ff6 (swap): 53 57 41 50 53 50 41 43 45 32
  Physical volume "/dev/sdc3" successfully created.
  Volume group "vg_test" successfully created
  Logical volume "lv_tmp" created.
  LV     VG      Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  lv_tmp vg_test -wi-ao---- 1020.00m
hello from vg_test

This time the LV took every free extent with -l 100%FREE, which is fine for a test you’re about to delete. It isn’t in fstab, because it’s temporary. Now take it apart from the top down:

sudo umount /mnt/tmp
sudo lvremove vg_test/lv_tmp
sudo vgremove vg_test
sudo pvremove /dev/sdc3
sudo pvs
sudo wipefs /dev/sdc3

You should see something like this (answer y at the prompt):

Do you really want to remove active logical volume vg_test/lv_tmp? [y/n]: y
  Logical volume "lv_tmp" successfully removed.
  Volume group "vg_test" successfully removed
  Labels on physical volume "/dev/sdc3" successfully wiped.
  PV         VG      Fmt  Attr PSize  PFree
  /dev/sda3  rl      lvm2 a--  18.41g     0
  /dev/sdb   vg_data lvm2 a--  <5.00g <2.00g

lvremove asks before it removes an active LV, and deleting it destroys the file system and the note on it. vgremove and pvremove then work without a question because nothing depends on them any more, and wipefs shows sdc3 is back to an empty partition. Remove the mount point with sudo rmdir /mnt/tmp.

✅ Checkpoint: pvs no longer lists /dev/sdc3, wipefs prints nothing for it, and vg_data with its two LVs is untouched.