Prepare a Foreman Host on Azure

Prepare an AlmaLinux Azure host with LVM storage for a Foreman lab.

Introduction

30 Second Summary

A computer can look ready today. After its next restart, important files can seem to vanish when storage was connected only by hand.

In this project, you will prepare an AlmaLinux 9 virtual machine on Microsoft Azure as a Foreman lab host. The result is a reboot-safe LVM-backed XFS layout with a readiness audit that clearly marks its capacity as lab-sized.

What You'll Build

Your finished host comes back from a reboot with every Foreman storage path mounted automatically while one SSH session reveals active swap plus the complete readiness result.

By the end of this project, you'll have:

A reachable Azure host you can administer from your Mac, with SSH traffic on port 22 restricted to your current public IP.
An expandable 256 GiB storage pool that displays separate XFS capacity for /var/lib/pulp, /var/lib/pgsql, /var/log, /tmp, and /var/tmp, plus active swap.
A reboot-tested readiness report that confirms the host's CPU, memory, hostname, SELinux state, time synchronization, mounts, and swap while identifying the 160 GiB Pulp filesystem as lab-sized.
Secret Mission: Expand the mounted Pulp filesystem online by 8 GiB from the reserved LVM capacity.

Are there any prerequisites?

You need a macOS device plus an Azure subscription with permission to create compute, storage, and network resources. Costs vary by region plus subscription, so the cleanup section shows how to deallocate the VM or delete the lab.

Before We Start

This project prepares a lab-sized AlmaLinux OS 9 storage foundation for a future Foreman installation. The 256 GiB layout uses separate LVM-backed XFS paths to isolate Pulp content, PostgreSQL data, logs, and temporary data while remaining below Foreman's documented 300 GB runtime guidance for /var/lib/pulp.

Provision and Reach the AlmaLinux Host

A future Foreman installation needs a dedicated Enterprise Linux 9 host with enough compute capacity. This step creates that isolated foundation in Microsoft Azure.

Remote access over SSH exposes a route into the host. A separate Azure managed disk provides the capacity for the LVM work that follows.

In this step, get ready to:

Provision an AlmaLinux 9 VM with Foreman-ready compute capacity.
Restrict remote access to your current public IP address.
Prove that your Mac can reach the host plus its attached data disk.

Provision the AlmaLinux VM

An Azure virtual machine turns the lab design into a dedicated Linux host. The selected size provides 4 vCPUs plus 32 GiB of memory.

Sign in to the Azure portal with the subscription you are using for this project.
Open Virtual machines from the Azure portal.
Select Create.
Select Virtual machine.
Select Create new beside Resource group.
Enter rg-foreman-lab as the resource group name.
Enter foreman-lab as the virtual machine name.
Choose the Azure region where you want the lab resources to run.

Why use a dedicated host?

Foreman 5.0 expects a freshly provisioned system that serves no other role. A dedicated VM keeps this storage lab isolated from other workloads.

Open the Image selector.
Select See All Images.
Search for AlmaLinux.
Select the official AlmaLinux OS 9 x86_64 Gen2 image.
Select Standard_E4s_v5 as the VM size.
Select Standard_E4as_v5 only if the primary size is unavailable in your region.
Set the OS disk type to Standard SSD LRS.
Set the OS disk size to 64 GiB.

Why this VM size?

Both supported VM sizes provide 4 vCPUs plus 32 GiB of memory. That clears Foreman's documented minimum of 4 CPU cores plus 20 GB of RAM.

The portal-generated private key controls access to the VM. Keep the downloaded file private because anyone who obtains it can attempt to authenticate as your Linux user.

Set Authentication type to SSH public key.
Select Generate new key pair as the SSH public key source.
Enter azureuser as the administrator username.
Enter foreman-lab-key as the key pair name.
Keep the portal options that create public networking for SSH.
Submit the VM deployment after the portal validation passes.
Download foreman-lab-key.pem into your Mac's Downloads folder when prompted.

Azure can take several minutes to finish the deployment. A quiet progress screen during this wait is expected.

Return to the foreman-lab overview when the deployment completes.
Confirm the VM status shows that it is running.
Confirm the VM size shows Standard_E4s_v5 or Standard_E4as_v5.
Confirm the OS disk shows 64 GiB with Standard SSD LRS storage.

Your dedicated AlmaLinux host is now running with the compute capacity this lab needs.

VM deployment did not complete?

Check whether the selected VM size is available in your region. Use the documented fallback size if the primary size cannot be allocated.

Review the deployment details for a subscription quota or permission problem.

Ask for help with the deployment details you see.

Restrict SSH and attach the data disk

A network security group controls which network traffic can reach the VM. Only your current public IP should reach TCP port 22.

Open the network settings from the foreman-lab menu.
Select the existing inbound SSH rule for port 22.
Set Source to My IP address.
Set the protocol to TCP.
Set the destination port to 22.
Set the action to Allow.
Apply the inbound rule changes.
Confirm the rule source shows your current public IP address.

The inbound rule now limits public SSH access to your current internet connection.

Why restrict the source address?

Port 22 accepts remote administration traffic. Restricting its source reduces exposure while the VM has a public IP address.

Attaching the 256 GiB disk starts managed-disk storage charges based on its provisioned size. You can remove the entire lab resource group after finishing the project.

Open Settings from the foreman-lab menu.
Select Disks.
Select Create and attach a new disk.
Set Storage type to Standard SSD LRS.
Set Size (GiB) to 256.
Set the disk LUN to 0.
Set Host caching to None.
Select Save.

Confirm the attached disk row shows 256 GiB with LUN 0.
Confirm the disk uses Standard SSD LRS storage.
Confirm host caching shows None.

The VM now has the blank data disk that becomes your LVM storage pool in the next step.

Disk settings do not match?

Check that you edited the new data disk instead of the 64 GiB OS disk. The data disk must show 256 GiB at LUN 0.

Ask for help before continuing if the disk row shows a different size or caching mode.

Connect from your Mac and identify LUN 0

macOS includes OpenSSH for secure remote connections. The downloaded key must have restrictive permissions before OpenSSH accepts it.

Press Cmd+Space on your Mac to open search.
Type Terminal to find the terminal application.
Press Enter to open Terminal.
Secure the downloaded private key by running this command:

chmod 400 ~/Downloads/foreman-lab-key.pem

What does this permission change do?

The chmod command limits the key file to read access for your macOS account. Mode 400 prevents other local users from reading it.

The command returns to your prompt without output when the permission change succeeds.

Permission command failed?

Confirm that foreman-lab-key.pem exists in your Downloads folder. Check that the filename has not gained an extra download suffix.

Ask for help locating or securing the downloaded key.

The VM's public IP is the address OpenSSH uses from your Mac. Your first connection may ask you to trust the host key.

Return to the foreman-lab overview in the Azure portal.
Copy the VM's public IP address.
Switch back to Terminal on your Mac.
Connect to the VM by replacing <public-ip> in this command with the copied address:

ssh -i ~/Downloads/foreman-lab-key.pem azureuser@<public-ip>

What does this connection command do?

OpenSSH uses -i to select the downloaded identity file. It authenticates to the VM as azureuser.

You will see an AlmaLinux shell prompt when the connection succeeds.

Cannot reach the VM?

Confirm the VM is running. Check that the copied public IP still matches the address on the VM overview.

Confirm the inbound SSH rule uses your current public IP. Your address can change when you switch networks.

Ask for help diagnosing the connection without sharing your private key.

Before you inspect the disks, do you expect the newly attached data disk to contain a filesystem yet?

Inspect the VM's block devices plus its Azure SCSI links by running:

lsblk
sudo ls -alF /dev/disk/azure/scsi1/

What do these commands prove?

The first command lists the OS disk plus the attached 256 GiB data disk.
The second command reveals which Linux device the Azure LUN 0 link targets.
Together they let you identify the correct disk without guessing a device name.

You will see the OS disk plus a separate 256 GiB disk with no filesystem or mount. The lun0 link under /dev/disk/azure/scsi1/ points to that unformatted disk.

Match the lun0 link target to the 256 GiB row in the block-device output.
Record the matched device here: your LUN 0 device path.

Cannot identify the data disk?

Do not choose a device based only on its name. Compare the 256 GiB size with the target of the lun0 link.

Return to the Azure disk settings if no 256 GiB disk appears. Confirm the data disk is attached to foreman-lab at LUN 0.

Ask for help interpreting the two command outputs before changing any storage.

That is the access layer complete. Your AlmaLinux VM is reachable from your Mac plus its unformatted data disk is ready for LVM preparation.

Build the First Volume

Your Azure host is reachable over SSH. Its 256 GiB managed disk is still raw capacity.

Foreman benefits from storage paths with separate capacity boundaries. In this step, you will use LVM to create the first boundary. A reboot will test which parts of the storage setup persist without extra configuration.

In this step, get ready to:

Confirm the required LVM2 and XFSprogs package builds.
Turn the Azure data disk into an LVM volume group with a 160 GiB Pulp volume.
Reboot the VM to test whether the manual mount returns.

Confirm the storage tools and initialize LVM

LVM2 manages physical volumes. XFSprogs provides the tools for creating an XFS filesystem. The pinned package builds keep your commands aligned with this AlmaLinux 9 lab.

Enter an administrative shell in the SSH session from the previous step by running this command:

sudo -i

What does this command do?

The command starts a root login shell. Your prompt changes to show that later storage commands have administrative access.

Check the installed LVM2 and XFSprogs package builds by running this command:

rpm -q lvm2 xfsprogs

What does this package check show?

The package query prints the installed build for each storage tool. It also identifies any package that is missing.

✔️ Both packages match the required builds

You should see lvm2-2.03.33-4.el9_8.1.x86_64 plus xfsprogs-6.4.0-7.el9.x86_64. Your storage tools are ready.

ⓧ I see older package builds

The installed packages do not match the required builds. Use dnf to install the pinned packages.

Install the required package builds by running this command:
Approve the transaction if dnf asks for confirmation.

dnf install lvm2-2.03.33-4.el9_8.1 xfsprogs-6.4.0-7.el9
rpm -q lvm2 xfsprogs

What does this installation do?

The first command installs the pinned LVM2 and XFSprogs builds from the AlmaLinux repositories. The package query confirms the builds that are now installed.

Package installation failed?

Confirm that the VM still has internet access. Check that the package names match the command exactly.

Help me diagnose the DNF package installation.

ⓧ One or both packages are missing

One or both storage packages are absent. Install both pinned builds before changing the disk.

Install the required package builds by running this command:
Approve the transaction if dnf asks for confirmation.

dnf install lvm2-2.03.33-4.el9_8.1 xfsprogs-6.4.0-7.el9
rpm -q lvm2 xfsprogs

What does this installation do?

The first command adds the LVM and XFS utilities to the VM. The package query confirms that both required builds are present.

Packages still missing?

Confirm that the installation transaction completed. A failed repository connection can leave the packages uninstalled.

Help me install the missing storage packages.

A physical volume registers a disk with LVM. A volume group combines that capacity into a pool that can be divided later.

Reconfirm the Azure LUN 0 path against the unformatted 256 GiB disk by running these commands:

lsblk
sudo ls -alF /dev/disk/azure/scsi1/

What are you confirming?

The block-device list separates the 64 GiB operating-system disk from the 256 GiB data disk.
The Azure device directory shows where lun0 points on this VM.

You should see /dev/disk/azure/scsi1/lun0 resolve to the unformatted 256 GiB data disk.

This next change is destructive for the selected disk. The LUN path protects your operating-system disk only when your inspection confirms the correct target.

Initialize the confirmed LUN 0 disk as a physical volume by running these commands:

pvcreate /dev/disk/azure/scsi1/lun0
vgcreate vg_foreman /dev/disk/azure/scsi1/lun0
pvs
vgs

How does the LVM pool work?

The first command records LVM metadata on the Azure data disk.
The second command creates vg_foreman as the shared capacity pool.
The final checks show the physical volume plus the volume group's available capacity.

You should see one physical volume assigned to vg_foreman. The volume group should report capacity close to the attached disk size.

Physical volume creation failed?

Stop if the command reports that the device is mounted or already contains data. Recheck the LUN 0 link against the 256 GiB disk before retrying.

Help me verify the correct Azure data disk.

Create and mount the Pulp volume

A logical volume carves a defined amount of space from the volume group. The 160 GiB Pulp volume leaves capacity for the remaining Foreman paths plus a growth reserve.

Create the Pulp logical volume and format it with XFS by running these commands:

lvcreate -n lv_pulp -L 160G vg_foreman
mkfs.xfs /dev/vg_foreman/lv_pulp
lvs

What did these commands create?

The logical-volume command allocates 160 GiB from vg_foreman to lv_pulp.
The format command creates an XFS filesystem on that logical volume.
The final report confirms the new logical volume and its size.

You should see lv_pulp listed inside vg_foreman with a size of 160 GiB.

Logical volume or format failed?

Use the volume-group report to confirm that enough free capacity remains. Check that the logical-volume path matches the command exactly.

Help me diagnose the Pulp volume creation.

Mount the new filesystem and create its marker file by running these commands:

mkdir -p /var/lib/pulp
mount /dev/vg_foreman/lv_pulp /var/lib/pulp
touch /var/lib/pulp/storage-check.txt
findmnt -o SOURCE,TARGET /dev/vg_foreman/lv_pulp
ls -l /var/lib/pulp/storage-check.txt
pvs
vgs
lvs

What proves the filesystem works?

The mount command attaches the XFS filesystem to /var/lib/pulp.
The marker file stores visible proof inside lv_pulp.
The storage reports show the mount source plus the remaining unallocated capacity in vg_foreman.

That is the first storage slice working. You can see the mounted logical volume plus storage-check.txt inside it.

Marker file not visible?

Confirm that findmnt reports /dev/mapper/vg_foreman-lv_pulp as the source for /var/lib/pulp. Check that every path uses the same spelling.

Help me fix the Pulp mount or marker file.

Reboot and inspect the missing mount

The logical volume now contains real data. The mount came from a manual command. The /etc/fstab file remains unchanged for this test.

Restart the AlmaLinux VM by running this command:

reboot

What does this reboot test?

The reboot ends your current SSH session. It forces AlmaLinux to reconstruct its storage state from configuration stored on disk.

Reconnect from macOS Terminal with the same private key by running this command:

ssh -i ~/Downloads/foreman-lab-key.pem azureuser@<public-ip>

What does this connection restore?

The command opens a fresh SSH session to foreman-lab using the private key secured in the previous step.

SSH connection not ready?

The VM may still be completing its restart. Wait briefly before retrying the same connection command.

Help me reconnect after the reboot.

Return to an administrative shell by running this command:

sudo -i

Why return to the root shell?

The root shell gives the storage-reporting commands consistent access to LVM and mount information.

Before you run the final check, do you think the logical volume and its mounted filesystem both returned after the reboot?

Compare the surviving logical volume with the current mount state by running these commands:

lvs
findmnt /var/lib/pulp

What did the reboot prove?

The lvs output still lists lv_pulp at 160 GiB. LVM metadata survived the restart.

The findmnt command returns no mounted filesystem for /var/lib/pulp. The marker remains stored inside the unmounted XFS filesystem, so the current directory hides it.

Is the Pulp filesystem still mounted?

A mounted result means another configuration restored the filesystem during boot. Confirm that no entry for /var/lib/pulp was added to /etc/fstab before this test.

Help me understand why the mount persisted.

You have exposed the missing persistence layer without losing the Pulp filesystem. Next, you will use the remaining capacity in vg_foreman to build the rest of the lab-sized storage layout.

Complete the LVM Layout

Your first LVM-backed filesystem survived the reboot as a logical volume. Its manual mount did not survive.

The remaining Foreman paths now need fixed capacity boundaries inside vg_foreman. The plan keeps about 40 GiB free for future growth.

In this step, get ready to:

Allocate the five remaining logical volumes inside vg_foreman.
Prepare the new logical volumes as XFS filesystems or swap.
Preserve the existing directory data through temporary staging mounts.

Create the remaining logical volumes

Each logical volume creates a capacity boundary for one host path. The five new volumes consume 56 GiB of the available space.

Allocate the planned capacities inside vg_foreman by running these commands in the administrative shell from earlier:

lvcreate --name lv_pgsql --size 24G vg_foreman
lvcreate --name lv_log --size 12G vg_foreman
lvcreate --name lv_tmp --size 8G vg_foreman
lvcreate --name lv_vartmp --size 8G vg_foreman
lvcreate --name lv_swap --size 4G vg_foreman
lvs -o lv_name,vg_name,lv_size
vgs

How the Capacity Plan Works

Each lvcreate command reserves a fixed portion of vg_foreman for one purpose.
The existing lv_pulp volume keeps its 160 GiB allocation.
The final two commands report every logical volume plus the remaining volume-group capacity.

You should see six logical volumes in the report. The volume group should show roughly 40 GiB free.

Missing a Logical Volume?

A partial run can leave some new logical volumes in place. Compare the displayed names with the planned list before retrying any creation command.

If the free capacity is much lower than expected, stop before formatting anything.

Help me inspect an unexpected LVM layout before I continue.

Format the new storage

The logical volumes currently provide capacity without a filesystem. The existing lv_pulp volume already contains XFS data, so these commands leave it untouched.

Create four new XFS filesystems plus the swap area by running these commands:

mkfs.xfs /dev/vg_foreman/lv_pgsql
mkfs.xfs /dev/vg_foreman/lv_log
mkfs.xfs /dev/vg_foreman/lv_tmp
mkfs.xfs /dev/vg_foreman/lv_vartmp
mkswap /dev/vg_foreman/lv_swap
sudo blkid

What Do These Commands Prepare?

Each mkfs.xfs command creates an XFS filesystem on one new logical volume.
The mkswap command initializes lv_swap for later activation.
The storage report exposes the filesystem type assigned to each logical volume.

You should see XFS associated with five logical volumes, including the existing lv_pulp. You should also see swap associated with lv_swap.

Do the Filesystem Types Look Wrong?

Check the logical-volume path carefully if a new volume is missing from the storage report. Do not format lv_pulp again because that would erase its marker file.

Help me diagnose a missing XFS or swap signature.

Stage the existing directory data

Mounting a new filesystem over a populated directory hides the directory's current contents. A temporary mount at /mnt gives the cp command a safe destination for preserving those contents first.

Stage the files from /var/log, /tmp, and /var/tmp by running these commands:

mount /dev/vg_foreman/lv_log /mnt
findmnt -o SOURCE,TARGET /dev/vg_foreman/lv_log
cp -a /var/log/. /mnt/
umount /mnt

mount /dev/vg_foreman/lv_tmp /mnt
findmnt -o SOURCE,TARGET /dev/vg_foreman/lv_tmp
cp -a /tmp/. /mnt/
chmod 1777 /mnt
umount /mnt

mount /dev/vg_foreman/lv_vartmp /mnt
findmnt -o SOURCE,TARGET /dev/vg_foreman/lv_vartmp
cp -a /var/tmp/. /mnt/
chmod 1777 /mnt
umount /mnt

How Staging Protects the Existing Data

Each volume is mounted temporarily at /mnt before receiving data.
The copy operation preserves ownership plus permissions from the source directory.
Mode 1777 keeps the new temporary-directory roots world-writable with sticky-bit protection.
Each unmount leaves the copied data stored inside its logical volume.

Each mount report should map the expected logical volume to /mnt. The three filesystems are unmounted after their data is copied.

Unable to Unmount the Staging Path?

Return your shell to a directory outside /mnt if the command reports that the target is busy.
Retry the affected copy if a temporary file disappeared while its source directory was changing.

Help me resolve a staging mount problem safely.

The copied data now lives inside the new filesystems. The final directories still need to exist before persistent mounts are configured in the next step.

Prepare the final mount-point directories plus verify the original Pulp marker by running these commands:

mkdir -p /var/lib/pulp /var/lib/pgsql /var/log /tmp /var/tmp
mount /dev/vg_foreman/lv_pulp /mnt
cat /mnt/storage-check.txt
umount /mnt

What Does This Final Preparation Prove?

The first command ensures every final mount-point directory exists.
The temporary Pulp mount exposes the marker stored inside lv_pulp.
The final unmount returns /mnt to an unused staging state.

You should see the marker text from the previous step. This confirms that the original Pulp filesystem remains intact.

Cannot See the Pulp Marker?

Confirm that the mounted source is /dev/vg_foreman/lv_pulp. A different source at /mnt exposes different data.

Help me locate the marker on lv_pulp without changing the filesystem.

Before you run the final report, how many logical volumes do you expect to see? How much capacity should remain free?

Run the final capacity report by running these commands:

lvs -o lv_name,vg_name,lv_size
vgs

How to Read the Final Report

The logical-volume report lists each name beside its volume group plus allocated size.
The volume-group report shows the unallocated capacity available for later expansion.

You should see lv_pulp, lv_pgsql, lv_log, lv_tmp, lv_vartmp, and lv_swap. The free capacity should be roughly 40 GiB.

Does the Final Report Differ?

Compare every displayed size with the capacity plan before continuing. An unexpected size can reduce the growth reserve needed later.

Help me compare my final LVM report with the planned layout.

That is the full storage plan in place: six logical volumes now have clear capacity boundaries plus room to grow. Next, you will make every filesystem mount automatically after a reboot.

Persist the Mounts and Swap

Your LVM layout now contains five prepared XFS filesystems plus a 4 GiB swap volume. The preserved directory contents are ready for their final paths.

The previous reboot exposed the missing persistence layer because the Pulp filesystem disappeared from its mount point. This step adds UUID-based entries to /etc/fstab so systemd can restore every mount during boot.

In this step, get ready to:

Declare the five XFS filesystems plus swap in /etc/fstab by UUID.
Restore SELinux labels on the mounted paths.
Reboot the VM to verify persistent storage.

Add UUID-based fstab entries

A filesystem UUID stays tied to the filesystem even if Linux assigns a different device path after a restart. The backup gives you a clean recovery point before changing the boot configuration.

Back up /etc/fstab by running this command:

cp /etc/fstab /etc/fstab.bak

What does this command do?

The command copies the current configuration to /etc/fstab.bak. You can use that untouched copy if an entry needs to be corrected.

Display the filesystem identifiers by running:

sudo blkid

Why use UUIDs?

The output associates each logical volume with its filesystem UUID. UUID-based mounts remain reliable when device names change between boots.

Record the UUID beside lv_pulp here: lv_pulp filesystem UUID.
Record the UUID beside lv_pgsql here: lv_pgsql filesystem UUID.
Record the UUID beside lv_log here: lv_log filesystem UUID.
Record the UUID beside lv_tmp here: lv_tmp filesystem UUID.
Record the UUID beside lv_vartmp here: lv_vartmp filesystem UUID.
Record the UUID beside lv_swap here: lv_swap UUID.

The terminal editor opens interactively. Keep every existing operating-system entry in the file.

Open /etc/fstab in the terminal editor by running:

vi /etc/fstab

Protect the existing entries

The existing lines mount the operating-system filesystems. Add the Foreman storage entries below those lines without replacing the original content.

Append these entries to the end of /etc/fstab by copying the block below:

# Foreman lab filesystems use UUIDs so device names can change safely
UUID=[[PULP_UUID="lv_pulp filesystem UUID"]] /var/lib/pulp xfs defaults,nofail 0 0
UUID=[[PGSQL_UUID="lv_pgsql filesystem UUID"]] /var/lib/pgsql xfs defaults,nofail 0 0
UUID=[[LOG_UUID="lv_log filesystem UUID"]] /var/log xfs defaults,nofail 0 0
UUID=[[TMP_UUID="lv_tmp filesystem UUID"]] /tmp xfs defaults,exec,nofail 0 0
UUID=[[VARTMP_UUID="lv_vartmp filesystem UUID"]] /var/tmp xfs defaults,nofail 0 0
# Swap activates automatically during boot
UUID=[[SWAP_UUID="lv_swap UUID"]] none swap defaults 0 0

What do these entries control?

The defaults option applies standard mount behavior. The nofail option lets the VM finish booting if a data filesystem is unavailable.
The /tmp entry includes exec because Foreman requires an executable separate temporary filesystem.
The swap entry uses none swap defaults 0 0 so the 4 GiB logical volume activates during boot.

Save /etc/fstab using the editor's write control.
Exit the terminal editor.

✔️ Awesome, I've got everything!

Your original entries remain in place. The six Foreman storage entries now appear at the end of /etc/fstab.

ⓧ I'd like to double check the full code

Compare the Foreman storage section at the end of your existing /etc/fstab file with this reference. Your original operating-system entries must remain above it.

# Foreman lab filesystems use UUIDs so device names can change safely
UUID=[[PULP_UUID="lv_pulp filesystem UUID"]] /var/lib/pulp xfs defaults,nofail 0 0
UUID=[[PGSQL_UUID="lv_pgsql filesystem UUID"]] /var/lib/pgsql xfs defaults,nofail 0 0
UUID=[[LOG_UUID="lv_log filesystem UUID"]] /var/log xfs defaults,nofail 0 0
UUID=[[TMP_UUID="lv_tmp filesystem UUID"]] /tmp xfs defaults,exec,nofail 0 0
UUID=[[VARTMP_UUID="lv_vartmp filesystem UUID"]] /var/tmp xfs defaults,nofail 0 0
# Swap activates automatically during boot
UUID=[[SWAP_UUID="lv_swap UUID"]] none swap defaults 0 0

Unsure about an fstab entry?

Compare each recorded UUID with the matching logical volume in the earlier output.
Confirm that every filesystem entry contains six fields.
Keep the backup at /etc/fstab.bak until the reboot test passes.

Ask for help checking the file before you continue: help me review these UUID-based fstab entries for five XFS mounts and one swap volume

Test mounts and activate swap

A malformed entry can interrupt the next boot. Testing the file now gives you a safe chance to fix its fields while the current SSH session still works.

Regenerate the mount units by running these commands:

systemctl daemon-reload
mount -a
swapon -v /dev/vg_foreman/lv_swap

What do these commands prove?

The first command makes systemd read the updated /etc/fstab configuration.
The second command tests the filesystem entries by mounting each available target.
The third command activates lv_swap before the reboot.

Inspect the active mounts plus swap by running:

findmnt
swapon --show

What should you check?

The mount table should associate the five Foreman paths with their logical volumes. The swap table should show the 4 GiB lv_swap volume as active.

You should now see separate mounts for /var/lib/pulp, /var/lib/pgsql, /var/log, /tmp, plus /var/tmp. The /tmp mount options should include exec.

Did the fstab test report a problem?

Stop before rebooting the VM.
Compare the affected line with the matching UUID from sudo blkid.
Check the filesystem type plus the six fields on that line.

Get help with the specific entry here: help me diagnose why mount -a or swap activation failed after I edited /etc/fstab

Restore labels and prove persistence

Mounting new filesystems over system paths can expose files with labels that do not match their final locations. SELinux uses those labels when deciding which services can access each path.

Restore the default labels plus temporary-directory permissions by running:

restorecon -Rv /var/lib/pulp /var/lib/pgsql /var/log /tmp /var/tmp
chmod 1777 /tmp
chmod 1777 /var/tmp

Why restore labels and permissions?

The recursive label restoration aligns each mounted tree with the policy for its final path. The two permission commands preserve shared temporary-directory access with the sticky bit enabled.

Check the temporary-directory permissions by running:

ls -ld /tmp /var/tmp

What should the permissions show?

Both directories should be writable plus searchable by every user. A lowercase t in the final execute position shows that the sticky bit remains enabled.

The reboot is the final persistence test. Expect the SSH connection to close while the VM restarts.

Before you reboot, do you expect all five XFS mounts plus swap to return automatically?

Restart the AlmaLinux VM by running:

systemctl reboot

What happens during the reboot?

The command ends your SSH session while the VM restarts. Systemd reads /etc/fstab during startup to mount the five filesystems plus activate swap.

Return to macOS Terminal after the VM has restarted.
Reconnect with the same restricted SSH command you used earlier.

The VM is back online. One final audit now checks the mounts from a fresh boot instead of the current shell state.

Verify the post-reboot storage state by running:

findmnt
df -Th
swapon --show
ls -l /var/lib/pulp/storage-check.txt

What proves persistence?

The mount output lists all five expected paths with XFS sources from vg_foreman.
The filesystem report shows separate capacity for each mounted logical volume.
The swap report shows the 4 GiB swap logical volume as active.
The final line lists /var/lib/pulp/storage-check.txt from the persistent Pulp filesystem.

Is a mount missing after reboot?

Compare the missing path with its UUID entry in /etc/fstab.
Confirm that the logical volume still appears in the earlier storage layout.
Correct the entry before running the mount test again.

Use this prompt to investigate the missing path: help me troubleshoot a UUID-based XFS mount or swap volume that did not return after reboot

That is the persistence layer proven. Your five XFS filesystems plus swap now return automatically without hiding the Pulp marker.

Next, you will audit the host against Foreman's operating-system plus capacity requirements.

Run the Foreman Readiness Audit

Your reboot-safe XFS storage is ready. The final goal is to prove the whole host is suitable for a Foreman lab.

Mounted filesystems cover only one part of readiness. The final audit checks every prerequisite from the SSH session you already use.

In This Step, Get Ready To:

Set the lab FQDN for local name resolution.
Audit the host against Foreman's published requirements.
Record the final lab-sizing verdict.

Set the Lab Hostname

A fully qualified domain name gives Foreman a stable system identity. This lab uses a local mapping to prove name resolution on the VM.

Return to the Microsoft Azure portal from earlier.
Select Virtual machines from the portal menu.
Select foreman-lab.
Select Network settings under Networking.
Select the linked network interface.
Select IP configurations under Settings.
Record the primary private IP address here: your VM private IP address.

Switch back to the SSH session from earlier.
Enter an administrative shell with the method from the storage steps.
Set the VM hostname by running this command:

hostnamectl set-hostname foreman.lab.example

What Does This Command Do?

The hostnamectl command sets the system hostname. foreman.lab.example becomes the lab identity used by the readiness checks.

Edit /etc/hosts with a terminal text editor in your administrative shell.
Add the following mapping on a new line:

[[VM_PRIVATE_IP="your VM private IP address"]] foreman.lab.example

How Does the Mapping Work?

This entry pairs the VM's private IP address with foreman.lab.example. Local hostname checks can now resolve the FQDN through /etc/hosts.

Save /etc/hosts.

Before you check, what hostname do you expect local resolution to return?

Verify the hostname plus local resolution by running these commands:

hostname -f
ping -c1 `hostname -f`

What Should You See?

The hostname -f command returns foreman.lab.example. The ping command resolves that name to your VM's private IP address.

Hostname Not Resolving?

Check that the IP address in /etc/hosts matches the primary private IP from the VM's network interface.
Confirm that foreman.lab.example uses the same spelling in both commands.
Save /etc/hosts before repeating the checks.

Help me troubleshoot the lab hostname mapping.

That host identity now works inside the VM. Your readiness audit can use a consistent FQDN.

Why Is This Lab-Only DNS?

The DNS mapping in /etc/hosts applies only to this VM. It does not publish the hostname to other systems.

A real Foreman installation still needs authoritative forward DNS. It also needs authoritative reverse DNS.

Audit Every Prerequisite

Foreman 5.0 defines a set of installation minimums. Your audit measures the VM against that published baseline.

Before you run the audit, which check do you expect to expose the lab's sizing limit?

Run the complete readiness audit from your SSH session with these commands:

cat /etc/os-release
uname -m
hostname -f
nproc
free -h
getenforce
timedatectl
findmnt
df -Th
swapon --show
vgs

How Do You Read the Audit?

The operating system output identifies AlmaLinux 9. The architecture output reads x86_64.
The hostname output reads foreman.lab.example.
The CPU output reads 4. The memory output shows about 32 GiB.
The SELinux output shows an enabled mode. The time output confirms that the system clock is synchronized.
The mount output lists all five persistent XFS filesystems. The /tmp mount permits executable content.
The swap output shows the active 4 GiB logical volume. The LVM report leaves roughly 40 GiB free in vg_foreman.

Does an Audit Value Differ?

Recheck the hostname configuration when hostname -f returns another name.
Use the findmnt output to identify any missing persistent mount.
Review the previous persistence step when the swap volume is absent from swapon --show.

Help me interpret a readiness audit value that differs from the expected Foreman lab result.

Record the Readiness Verdict

Capacity planning determines the verdict. Foreman 5.0 documents 300 GB of runtime capacity for /var/lib/pulp.

That measurement covers synchronized Enterprise Linux repositories from versions 7 through 9. Your mounted Pulp filesystem is 160 GiB.

Record the final result as Lab Ready, Not Production Sized.

Before the final storage check, do you expect the Pulp filesystem to meet the published runtime figure?

Verify the mounted filesystem sizes by running this command:

df -Th

What Confirms the Verdict?

The /var/lib/pulp row shows an XFS filesystem with about 160 GiB of capacity. That visible gap supports the lab-sizing label.

You have completed the full host audit from one SSH session. The VM now has a clear readiness result with its production limitation documented.

Secret mission

Grow Pulp Without Downtime

Use the reserved LVM capacity to expand the mounted Pulp filesystem by 8 GiB. Prove that its data stays available throughout the online growth.

Clean Up Your Resources

Choose whether to keep your Microsoft Azure lab running, deallocate its VM, or delete it. Deallocation stops compute billing, but the provisioned managed disks continue incurring storage charges.

Cost warning

Leaving foreman-lab allocated keeps compute billing active. Azure bills managed disks according to their provisioned size.

Choose Pause to stop compute billing. Choose Delete to remove the resources that continue generating charges.

Resources you used:

Azure resource group rg-foreman-lab.
Azure virtual machine foreman-lab with its 64 GiB OS disk, public IP address, network interface, virtual network, and network security group.
A 256 GiB Standard SSD LRS data disk containing the vg_foreman LVM volume group, six logical volumes, five XFS filesystems, and a 4 GiB swap area.
The local SSH private key at ~/Downloads/foreman-lab-key.pem.

Keep everything running

No action needed. Choose this if you plan to continue working with the Foreman lab host immediately.

Keep foreman-lab allocated so it remains available over SSH.
Keep foreman-lab-key.pem secured with permission mode 400.
Budget for VM compute charges and provisioned managed disk charges while the lab remains allocated.

Pause - I'll come back to this later

Shut down the VM to stop compute billing while keeping its disks for later. Your current SSH session ends during deallocation.

Return to the Microsoft Azure portal from earlier.
Select Virtual machines.
Select foreman-lab.
On the VM Overview page, select Stop.
Confirm the stop request in the prompt.
Wait until the VM reaches Stopped (deallocated).

That is the pause complete: compute billing has stopped for the VM. The managed disks remain provisioned and billable.

Delete - I don't want to use this again

Remove all project resources and start fresh. This permanently removes the VM, its disks, and the storage layout you built.

Deletion Removes the Whole Lab

Deleting rg-foreman-lab removes every Azure resource stored inside it. The LVM layout and readiness evidence on the VM disappear with the managed disks.

The downloaded private key remains on your Mac until you remove it separately.

Delete the Azure resources:

Save any screenshots or readiness evidence you want to keep.
Return to the Microsoft Azure portal from earlier.
Open rg-foreman-lab.
Select Delete resource group.
Enter rg-foreman-lab when Azure asks for the resource-group name.
Select Delete.
Confirm the deletion request.

When deletion finishes, rg-foreman-lab and every cloud resource listed above are gone.

Remove the local private key:

Remove the downloaded private key from your Mac by running this command:

rm -f ~/Downloads/foreman-lab-key.pem

What does this command do?

This removes only the downloaded Foreman lab private key from your Mac. Other files in your Downloads folder remain untouched.

Check ~/Downloads in Finder.

You should no longer see foreman-lab-key.pem in the folder.

Nice Work!

What a finish! Your AlmaLinux 9 lab host on Azure now boots with isolated storage ready for a future Foreman installation.

You've learned how to:

Provision a right-sized Azure VM with 4 vCPUs plus 32 GiB RAM. Reach it through restricted SSH access from your current public IP.
Convert a 256 GiB managed disk into an expandable LVM storage pool. Give each Foreman workload its own XFS capacity boundary.
Verify storage persistence across five XFS mounts plus 4 GiB of swap. Complete a Foreman 5.0 readiness audit for the host. Record the result as Lab Ready, Not Production Sized.
Secret Mission: Complete an online Pulp expansion from 160 GiB to 168 GiB. Keep storage-check.txt visible throughout the change.

Roughly 32 GiB remains free in vg_foreman for your next lab storage change.

Ready to quiz yourself?