Ansible Filesystems, LVM and Persistent Mounts
Storage is the part of the RHCSA-style objectives that people practise least, because getting it wrong on a real disk is expensive. A loop device removes that risk entirely: it is a file that behaves like a block device, so the whole stack - PV, VG, LV, filesystem, mount, fstab - can be built and torn down safely.
Automating Administration Guide 32 of 45 Advanced
- OSUbuntu 26.04 LTS
- ansible-core2.20.1
- Python3.14.4
- TimeAbout 18 min
This lab is Ubuntu 26.04 and EX294 is a RHEL exam. LVM and the modules used here are identical on both. The modules come from collections rather than ansible-core: community.general.lvg, lvol and filesystem, and ansible.posix.mount. All ship with the ansible package; on a bare ansible-core install they must be installed.
| Server Name | IP Address | OS | Roles | CPU | RAM | HDD |
|---|---|---|---|---|---|---|
| ANS-CTL01 | 192.168.0.36 | Ubuntu 26.04 LTS | Ansible Control Node | 2 Core | 3 GB | 50 GB |
| ANS-B01 | 192.168.0.38 | Ubuntu 26.04 LTS | Managed Node (group: db) | 2 Core | 3 GB | 50 GB |
This guide includes
Use this for the objectives people practise least. This matters because storage is a stack - device, volume group, logical volume, filesystem, mount - and the mount module's state is what decides whether it survives a reboot.
- creating a backing file that stands in for a real disk
- building LVM on top of it, one module per layer
- reading back what landed - the volume group and its free space
- understanding the four mount states, which is the parameter that actually matters
Before you start
- A control node configured as shown in the first step, and
lvm2on the managed node - the session installs it. - Everything is built on
/var/tmp/disk1.img, a file. No real disk is touched.
-
The configuration this guide assumes
-
A disk that is really a file
-
LVM on top of it
-
What landed
-
The four mount states