AlmaLinux 10 LVM on Azure User Guide

Overview

This guide covers the deployment and configuration of AlmaLinux 10 with its root filesystem on LVM on Microsoft Azure using cloudimg's pre configured virtual machine image from the Azure Marketplace.

AlmaLinux is a community owned enterprise Linux distribution, produced by the AlmaLinux OS Foundation to be binary compatible with Red Hat Enterprise Linux. AlmaLinux 10 runs the 6.12 kernel and follows the RHEL 10 lifecycle. What sets this image apart is the disk layout: the root filesystem lives on an LVM logical volume inside a volume group, rather than on a fixed partition, so you can grow it online, add capacity from new disks and take snapshots with the standard LVM tools.

AlmaLinux does not publish an LVM image of its own, so cloudimg builds this one from the official AlmaLinux 10 installation media with an automated installation, using the same package set and Azure configuration as the standard AlmaLinux 10 Azure image. The only intended difference is the disk layout.

What's included:

• AlmaLinux 10 (x86_64), binary compatible with RHEL 10
• Root filesystem on an LVM logical volume (volume group almalinux, logical volume root, XFS), with /boot and the EFI system partition as plain partitions
• The standard AlmaLinux 10 Azure image's package set, checked package for package
• Every available update applied at build time, and again immediately before capture
• Automatic updates installed, armed and enabled, so the machine keeps patching itself
• Azure Linux Agent (waagent) and cloud-init for Azure integration
• Chronyd for NTP time synchronisation against the Azure host clock
• SELinux in enforcing mode
• BaseOS, AppStream, CRB and Extras repositories enabled, so your update path is intact
• SSH as the only network listener, with no swap on the operating system disk and no swap volume
• Gen2 Hyper V virtual machine support
• 24/7 cloudimg support

Platform: Microsoft Azure (Gen2 Hyper V, x64) Default user: azureuser

This is the AlmaLinux 10 major release

This listing tracks the AlmaLinux 10 major release, not a frozen minor. RHEL family security fixes roll into the latest minor stream, so the image is built from whichever AlmaLinux 10 point release is current at build time and brought fully up to date. Your own dnf update then rolls the machine forward within AlmaLinux 10 in the normal way, so you keep receiving security fixes. AlmaLinux 10 has active support until May 2030 and security support until May 2035.

Security posture

This image ships with no known credential. There is no default password and no baked in SSH key:

• The root account password is locked, so no one can log in as root with a password.
• No account on the image has a usable password at all.
• PasswordAuthentication and keyboard interactive authentication are disabled in the SSH daemon, so every login is by key.
• PermitRootLogin is set to no, so root cannot log in over SSH at all. Use sudo from azureuser instead.
• SSH host keys are removed before capture and regenerated on each machine at first boot, so no two machines you launch share a host identity.
• /etc/machine-id is cleared before capture and regenerated per machine.
• The only key that works is the public key you supply when you create the virtual machine. Azure injects it into the administrator account you name at first boot.
• SELinux is left in enforcing mode, the AlmaLinux default.

Prerequisites

Before deploying this image, ensure you have:

1. An active Microsoft Azure subscription
2. Access to the Azure Portal or Azure CLI
3. An SSH key pair for Linux VM access
4. Familiarity with Azure VM management

Recommended VM Size: Standard_B2s (2 vCPU, 4 GB RAM) or larger.

Step 1: Deploy the Virtual Machine

Option A: Azure Portal

1. Navigate to the Azure Marketplace and search for "AlmaLinux 10 LVM cloudimg"
2. Select the image and click Create
3. Configure the basics:
4. Subscription: Select your Azure subscription
5. Resource Group: Create new or select existing
6. Virtual Machine Name: Enter a name for your VM
7. Region: Select your preferred region
8. Size: Standard_B2s recommended
9. Under Administrator Account, select SSH public key and enter your key
10. Under Disks, keep the default 30 GB operating system disk or choose a larger size (see Step 4 for claiming the extra space)
11. Under Inbound Port Rules, allow SSH (port 22)
12. Click Review + Create, then Create

Option B: Azure CLI

Run this on your own workstation, substituting your resource group, VM name and preferred region. Accept the Marketplace terms once per subscription, then create the machine:

az vm image terms accept --urn cloudimg1647283583153:almalinux-10-lvm:default:latest

az vm create \
  --resource-group myResourceGroup \
  --name my-almalinux-10-lvm-vm \
  --image cloudimg1647283583153:almalinux-10-lvm:default:latest \
  --size Standard_B2s \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

Add --os-disk-size-gb 64 (or any size above 30) to start with a larger operating system disk.

Step 2: Connect via SSH

Run these on your own workstation, not on the VM. Find the public IP, then connect:

az vm show --resource-group myResourceGroup --name my-almalinux-10-lvm-vm --show-details --query publicIps -o tsv
ssh azureuser@<vm-ip>

There is no password to enter. If SSH asks you for one, the key you supplied at create time is not the key your client is offering.

Step 3: Confirm the release

Check that the machine is AlmaLinux 10:

cat /etc/almalinux-release

AlmaLinux release 10.2 (Lavender Lion)

The os-release fields carry the same information in a machine readable form, which is what configuration management tools read:

grep -E '^(NAME|VERSION|ID|VERSION_ID|PLATFORM_ID)=' /etc/os-release

NAME="AlmaLinux"
VERSION="10.2 (Lavender Lion)"
ID="almalinux"
VERSION_ID="10.2"
PLATFORM_ID="platform:el10"

The RHEL compatibility lineage is asserted by the distribution itself, and the kernel is the AlmaLinux 10 build for x86_64:

cat /etc/redhat-release
uname -srm

AlmaLinux release 10.2 (Lavender Lion)
Linux 6.12.0-211.53.1.el10_2.x86_64 x86_64

AlmaLinux 10 for x86_64 is compiled for the x86-64-v3 processor level, which every current Azure x64 size provides. The system loader reports which levels the processor supports:

/lib64/ld-linux-x86-64.so.2 --help | grep -E 'x86-64-v[234]'

  x86-64-v4 (supported, searched)
  x86-64-v3 (supported, searched)
  x86-64-v2 (supported, searched)

The top line depends on the processor behind your VM size; x86-64-v3 (supported, searched) is the one AlmaLinux 10 needs.

The version reported is the current AlmaLinux 10 point release the image was patched to. This listing tracks the 10 major release, so dnf update rolls it forward across future point releases.

Step 4: The LVM disk layout

This is what sets this image apart: the root filesystem sits on an LVM logical volume inside a volume group, not on a fixed partition. The /boot and EFI system partitions stay as plain partitions, which is what the firmware and boot loader need:

df -hT / /boot /boot/efi

Filesystem                 Type  Size  Used Avail Use% Mounted on
/dev/mapper/almalinux-root xfs    29G  1.6G   28G   6% /
/dev/sda2                  xfs   960M  244M  717M  26% /boot
/dev/sda1                  vfat  200M  9.1M  191M   5% /boot/efi

One physical volume, the third partition of the operating system disk, backs the volume group almalinux, and the volume group holds a single logical volume, root. There is no swap volume:

sudo pvs
sudo vgs
sudo lvs -o lv_name,vg_name,lv_size,lv_path,devices

  PV         VG        Fmt  Attr PSize  PFree
  /dev/sda3  almalinux lvm2 a--  28.80g    0
  VG        #PV #LV #SN Attr   VSize  VFree
  almalinux   1   1   0 wz--n- 28.80g    0
  LV   VG        LSize  Path                Devices
  root almalinux 28.80g /dev/almalinux/root /dev/sda3(0)

The kernel command line tells the early boot environment which logical volume holds the root filesystem, and the LVM, partition growing and XFS tools are all installed:

grep -o 'root=[^ ]*\|rd.lvm[^ ]*' /proc/cmdline
rpm -q lvm2 cloud-utils-growpart xfsprogs

root=/dev/mapper/almalinux-root
rd.lvm.lv=almalinux/root
lvm2-2.03.36-2.el10.x86_64
cloud-utils-growpart-0.33-11.el10.noarch
xfsprogs-6.16.0-1.el10.x86_64

The same rd.lvm.lv=almalinux/root argument is recorded in /etc/kernel/cmdline, so every kernel that a future update installs boots from the logical volume too.

Growing the root filesystem

The volume group ships with no free space, and enlarging the Azure disk does not grow the root volume on its own. cloud-init's automatic partition growth deliberately skips a root filesystem on a logical volume, so the extra capacity stays unallocated until you claim it. After you create the machine with a larger disk (--os-disk-size-gb), or resize the disk in Azure (stop and deallocate the VM, raise the size, start it again), run the block below. Every step works online, with no reboot, and the last lines confirm that the whole chain took effect:

sudo growpart /dev/sda 3
sudo pvresize /dev/sda3
sudo lvextend -l +100%FREE /dev/almalinux/root
sudo xfs_growfs /
df -h /
FREE=$(sudo vgs --noheadings -o vg_free_count almalinux | tr -dc '0-9')
PVB=$(sudo pvs --noheadings --units b --nosuffix -o pv_size /dev/sda3 | tr -dc '0-9')
PARTB=$(( $(cat /sys/class/block/sda3/size) * 512 ))
if [ "${FREE:-1}" -eq 0 ] && [ "$(( PARTB - PVB ))" -le 8388608 ]; then echo "root volume fully extended: 0 free extents in VG almalinux, and the physical volume fills the partition"; else echo "NOT fully extended: ${FREE:-?} free extents in VG almalinux, partition ${PARTB} B vs physical volume ${PVB:-?} B"; false; fi

growpart extends partition 3 to the end of the disk, pvresize makes LVM see the larger physical volume, lvextend hands all the free space to the root logical volume and xfs_growfs grows the filesystem into it. On a machine created with a 64 GB disk, this is the output:

CHANGED: partition=3 start=2508800 old: size=60403712 end=62912511 new: size=131708895 end=134217694
  Physical volume "/dev/sda3" changed
  1 physical volume(s) resized or updated / 0 physical volume(s) not resized
  Size of logical volume almalinux/root changed from 28.80 GiB (7373 extents) to 62.80 GiB (16077 extents).
  Logical volume almalinux/root successfully resized.
meta-data=/dev/mapper/almalinux-root isize=512    agcount=4, agsize=1887488 blks
...
data blocks changed from 7549952 to 16462848
Filesystem                  Size  Used Avail Use% Mounted on
/dev/mapper/almalinux-root   63G  2.2G   61G   4% /
root volume fully extended: 0 free extents in VG almalinux, and the physical volume fills the partition

If the disk has not been enlarged, growpart prints NOCHANGE and lvextend reports that the size already matches. That is expected, and the final check still confirms the volume fills the disk. The two checks at the end catch the two ways a grow can silently stop short: free extents left in the volume group mean lvextend did not run, and a physical volume smaller than its partition means pvresize did not. Confirm the physical volume name with sudo pvs first; it is /dev/sda3 on this image.

Adding a data volume

Attach a new managed data disk in Azure. The portal and CLI show its LUN, and the matching device appears as /dev/disk/azure/data/by-lun/<N> (the older /dev/disk/azure/scsi1/lun<N> name works too). Give it its own volume group, which keeps application data separate from the operating system:

sudo pvcreate /dev/disk/azure/data/by-lun/0
sudo vgcreate datavg /dev/disk/azure/data/by-lun/0
sudo lvcreate -n datalv -l 100%FREE datavg
sudo mkfs.xfs /dev/datavg/datalv
sudo mkdir -p /data
echo '/dev/datavg/datalv /data xfs defaults,nofail 0 0' | sudo tee -a /etc/fstab
sudo systemctl daemon-reload
sudo mount /data

The nofail option lets the machine still boot if the data disk is ever detached. To add the disk's capacity to the root volume instead, use sudo vgextend almalinux /dev/disk/azure/data/by-lun/0 followed by the lvextend and xfs_growfs steps above.

The image ships /etc/lvm/devices empty, exactly like the standard AlmaLinux 10 Azure image, so LVM sees every attached disk and a machine cloned from this image does not carry a record of the build machine's disks.

Step 5: Check the patch level and automatic updates

Every available update was applied when this image was built. dnf check-update exits 100 when updates are pending and 0 when none are:

dnf -q check-update >/dev/null 2>&1; echo "exit=$?"

exit=0

Nothing is waiting on a reboot either:

dnf needs-restarting -r

No core libraries or services have been updated since boot-up.
Reboot should not be necessary.

One kernel version is installed, the one the machine is running. Like the standard AlmaLinux 10 Azure image, it also carries the debug build of that same kernel, which you can select from the boot menu when diagnosing a kernel problem. The machine boots the regular kernel by default:

rpm -q kernel-core kernel-debug-core
sudo grubby --default-kernel

kernel-core-6.12.0-211.53.1.el10_2.x86_64
kernel-debug-core-6.12.0-211.53.1.el10_2.x86_64
/boot/vmlinuz-6.12.0-211.53.1.el10_2.x86_64

Your update path is intact. BaseOS, AppStream, CRB (CodeReady Builder) and Extras are all enabled, which is the AlmaLinux 10 cloud image default:

dnf repolist --enabled

repo id                          repo name
appstream                        AlmaLinux 10 - AppStream
baseos                           AlmaLinux 10 - BaseOS
crb                              AlmaLinux 10 - CRB
extras                           AlmaLinux 10 - Extras

Automatic updates

The standard AlmaLinux 10 Azure image does not include dnf-automatic. This image installs it and enables its timer, so the machine applies updates on its own schedule:

systemctl is-enabled dnf-automatic.timer

enabled

systemctl cat dnf-automatic.timer | grep -E 'OnCalendar|RandomizedDelaySec'

OnCalendar=*-*-* 6:00
RandomizedDelaySec=60m

The policy applies all available updates, not only those tagged as security errata, and never reboots automatically, so a kernel update waits for a window you choose rather than restarting a production machine without warning:

grep -E '^(apply_updates|upgrade_type|download_updates|reboot) ' /etc/dnf/automatic.conf

upgrade_type = default
download_updates = yes
apply_updates = yes
reboot = never

upgrade_type is deliberately default rather than security. A security only policy depends on errata metadata being present for every update, and where it is not, it silently applies nothing, so default is the setting that actually keeps the machine current. Because reboot = never, check periodically whether a restart is owed after a kernel update, using the needs-restarting -r command above. To opt out entirely, run sudo systemctl disable --now dnf-automatic.timer.

Step 6: Verify the security posture

Confirm SELinux is enforcing:

getenforce

Enforcing

Confirm the root account is locked. The L in the second field means locked:

sudo passwd -S root

root L never 0 99999 7 -1

Confirm no account on the machine has a usable password. This prints nothing on a clean image:

sudo awk -F: '($2 !~ /^[!*]/) && ($2 != "") {print $1}' /etc/shadow

Read the SSH daemon's effective policy rather than the config file, since the running daemon is what a client actually meets:

sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|pubkeyauthentication|kbdinteractiveauthentication) '

permitrootlogin no
pubkeyauthentication yes
passwordauthentication no
kbdinteractiveauthentication no

That policy is pinned by a drop in file that sorts ahead of every other SSH configuration file, so a later package update to the main configuration cannot quietly loosen it:

sudo grep -vE '^#' /etc/ssh/sshd_config.d/00-cloudimg-hardening.conf

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitEmptyPasswords no

There is no swap on the operating system disk and no swap logical volume. Swap baked into a Marketplace image is not permitted, so this prints nothing:

swapon --show

Confirm what is listening. SSH on port 22 is the only service reachable from the network. The only other socket is chronyd, bound to the loopback address for time synchronisation:

ss -tln
ss -uln

State  Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0      128          0.0.0.0:22        0.0.0.0:*
LISTEN 0      128             [::]:22           [::]:*
State  Recv-Q Send-Q Local Address:Port Peer Address:Port
UNCONN 0      0          127.0.0.1:323       0.0.0.0:*
UNCONN 0      0              [::1]:323          [::]:*

The image ships nfs-utils for NFS version 4 client mounts, which need no extra listener. The rpcbind service that NFS version 3 relies on is installed but disabled, so port 111 stays closed:

systemctl is-enabled rpcbind.socket rpcbind.service || true

disabled
disabled

If you need NFS version 3, enable it with sudo systemctl enable --now rpcbind.socket and open only what you need in your Network Security Group.

Step 7: Verify Azure integration

The Azure Linux Agent handles extensions and the portal's recovery features, and cloud-init provisions the machine:

systemctl is-active waagent
rpm -q WALinuxAgent cloud-init chrony

active
WALinuxAgent-2.14.0.1-3.el10.noarch
cloud-init-24.4-7.el10_2.1.noarch
chrony-4.8-2.el10.x86_64

Cloud-init should report done, which means provisioning finished cleanly:

cloud-init status

status: done

The kernel puts a console on ttyS0, which is what makes boot diagnostics and the portal's serial console work when you cannot reach the machine over SSH:

grep -o 'console=ttyS0' /proc/cmdline

console=ttyS0

Time synchronisation runs through chronyd against the Azure host clock (your offsets will differ):

chronyc -n sources | head -4

MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
#* PHC0                          2   3   377    10    -58us[  -68us] +/-   11us

Sizes with a local temporary disk, such as Standard_B2s, have it formatted and mounted at /mnt by cloud-init. Treat anything on it as disposable, since it is erased whenever the machine is deallocated or moved:

findmnt -no SOURCE,FSTYPE,TARGET /mnt

/dev/sdb1 ext4 /mnt

Step 8: Networking and the firewall

The Azure Network Security Group is the control plane for inbound and outbound traffic, and it is the first and usually the only place you need to open a port.

firewalld is not installed on this image:

rpm -q firewalld || echo "(firewalld absent - the Azure NSG is your only firewall)"

package firewalld is not installed
(firewalld absent - the Azure NSG is your only firewall)

That matches the standard AlmaLinux 10 Azure image: with no host firewall in the way, your NSG rules take effect exactly as written, with no second layer to keep in sync. If your policy requires a host firewall as well, install and enable it yourself:

sudo dnf install -y firewalld
sudo systemctl enable --now firewalld
sudo firewall-cmd --permanent --add-port=443/tcp
sudo firewall-cmd --reload

Once firewalld is running, a port must be open in both the Azure NSG and firewalld before traffic reaches your service.

Step 9: Install software

AppStream carries the application packages:

dnf -q list --available nginx 2>/dev/null | tail -2

Available Packages
nginx.x86_64                    2:1.26.3-6.el10_2.6                    appstream

Install a package and enable it in the usual way, for example sudo dnf install -y nginx followed by sudo systemctl enable --now nginx, then open the port in your Network Security Group. Application data that grows, such as databases and web content, is a natural fit for its own logical volume on a data disk (see Step 4).

To add another administrator, create the account with sudo adduser <name>, add it to the wheel group with sudo usermod -aG wheel <name>, then copy your public key into /home/<name>/.ssh/authorized_keys with mode 600 and the .ssh directory mode 700, owned by that user. The image ships with no human accounts at all, so the administrator you named at create time is the only login until you add one:

getent group wheel

Common Use Cases

• RHEL 10 compatible servers whose storage needs to grow online without repartitioning
• Database and application hosts that keep data on separate logical volumes and data disks
• Environments whose build standards or compliance baselines require LVM managed storage
• A consistent LVM base for fleets managed by Ansible, Puppet or Salt

Troubleshooting

Cannot connect via SSH

Check the Network Security Group allows inbound TCP 22 from your address, confirm the machine is running, and make sure your client is offering the private key that matches the public key you supplied at create time. Password authentication is disabled, so a password prompt means key negotiation already failed. Root login over SSH is disabled too, so connect as the administrator you named at create time.

az vm show --resource-group myResourceGroup --name my-almalinux-10-lvm-vm --show-details --query powerState -o tsv

The VM does not come back after a change

Open Boot diagnostics and the Serial console for the VM in the portal; both read from ttyS0. If the console stops at the early boot shell saying /dev/mapper/almalinux-root does not exist, the kernel was started without the rd.lvm.lv=almalinux/root argument, which usually means a custom kernel command line replaced the defaults. Every boot entry on this image carries it; check yours with sudo grubby --info=ALL | grep args.

The root filesystem did not grow after resizing the disk

That is expected on an LVM root. Run the grow block in Step 4. If growpart still prints NOCHANGE, confirm the resize reached the VM with sudo pvs and cat /sys/class/block/sda/size, and remember that Azure only applies a disk resize after the VM has been deallocated.

Azure agent not running

Check whether the agent is running and read its recent log:

systemctl is-active waagent
sudo journalctl -u waagent -n 20 --no-pager

If it reports anything other than active, start it:

sudo systemctl enable --now waagent

Package manager issues

Clear the metadata cache and rebuild it:

sudo dnf clean all
sudo dnf makecache

If a repository is unreachable, confirm the machine has outbound HTTPS and that DNS resolves, since AlmaLinux's mirror system is reached over both.

A service is blocked and the logs mention SELinux

SELinux is enforcing, which is the secure default and should stay that way. Look at the denial rather than disabling SELinux:

sudo ausearch -m AVC -ts recent </dev/null 2>/dev/null || echo "no recent AVC denials"

Most denials on a fresh machine come from software installed into a non standard path. Relabel with sudo restorecon -Rv /path before considering any policy change.

Important Notes

AlmaLinux is free and open source. It is not covered by a single licence: the distribution is a collection of free and open source licences across its package set, predominantly GPL and LGPL, with MIT, BSD, Apache and others. No subscription, entitlement or licence key is required, and no per seat cost applies.

AlmaLinux is a trademark of the AlmaLinux OS Foundation. cloudimg is not affiliated with or endorsed by the AlmaLinux OS Foundation, and uses the name only to identify the distribution this image contains.

AlmaLinux 10 follows the RHEL 10 lifecycle: active support runs until 31 May 2030 and security support until 31 May 2035. Check the AlmaLinux release notes for the dates that apply to your deployment.

Support

For assistance with this image, contact cloudimg support:

• Website: www.cloudimg.co.uk
• Product Catalogue: www.cloudimg.co.uk/products
• User Guides: www.cloudimg.co.uk/guides
• SLA: 24 hour response guaranteed