Ubuntu 26.04 LVM

Option A: Azure Portal

• Navigate to the Azure Marketplace and search for "Ubuntu 26.04 LTS LVM SecureAnyCloud".
• Select the image and choose Create.
• On the Basics tab, set Subscription to your Azure subscription and Resource Group to a new or existing group.
• Enter a Virtual Machine Name and select your preferred Region.
• Set Size to Standard_B2s (recommended).
• Under Administrator Account, select SSH public key and enter your key.
• Under Inbound Port Rules, allow SSH (port 22).
• On the Disks tab, set the OS disk size you want. Use more than 30 GiB if you plan to grow the root.
• Choose Review + Create, then Create.

Option B: Azure CLI

az vm image terms accept --urn sac1647283583153:ubuntu-26-04-lvm:default:latest
az vm create \
  --resource-group myResourceGroup \
  --name my-ubuntu-lvm-vm \
  --image sac1647283583153:ubuntu-26-04-lvm:default:latest \
  --size Standard_B2s \
  --os-disk-size-gb 64 \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

--os-disk-size-gb 64 deploys the 30 GiB image onto a 64 GiB disk. You claim the extra space online in Step 7 with three LVM commands.

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

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

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

Check that the machine is the Ubuntu 26.04 LTS release you expect:

grep -E '^(NAME|VERSION|ID|VERSION_ID|PRETTY_NAME)=' /etc/os-release uname -srm dpkg --print-architecture

Expected output:

PRETTY_NAME="Ubuntu 26.04.1 LTS" NAME="Ubuntu" VERSION_ID="26.04" VERSION="26.04.1 LTS (Resolute Raccoon)" ID=ubuntu Linux 7.0.0-1012-azure x86_64 amd64

Then confirm the defining property of this image: the root filesystem on an LVM logical volume.

findmnt -no SOURCE,FSTYPE /
sudo pvs
sudo vgs
sudo lvs

Expected output on a fresh VM deployed with the default 30 GiB disk:

/dev/mapper/ubuntu--vg-ubuntu--lv ext4 PV VG Fmt Attr PSize PFree /dev/sda3 ubuntu-vg lvm2 a-- <27.50g 0 VG #PV #LV #SN Attr VSize VFree ubuntu-vg 1 1 0 wz--n- <27.50g 0 LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert ubuntu-lv ubuntu-vg -wi-ao---- <27.50g

/ on /dev/mapper/ubuntu--vg-ubuntu--lv is what the standard image cannot give you: a root volume you can extend online and a volume group you can reshape.

The disk itself is GPT with a 512 MiB EFI system partition, a 2 GiB /boot partition, and the rest as the LVM physical volume. The boot partition is kept as a plain partition so the bootloader never depends on LVM activation.

VFree 0 is deliberate. The image ships with the root volume taking every extent, and growth comes from enlarging the disk, not from space held back.

The image is fully updated at build time. Confirm that no upgrades are pending and that the update path is intact:

apt-get -s -o APT::Get::Always-Include-Phased-Updates=true dist-upgrade | grep -c '^Inst ' | sed 's/^/pending upgrades: /' apt-mark showhold dpkg -l | awk '/linux-image-[0-9]/{print $2, $3}'

Expected output shows pending upgrades: 0, no held packages, and the installed Azure kernel:

pending upgrades: 0 linux-image-7.0.0-1012-azure 7.0.0-1012.12

The Always-Include-Phased-Updates=true flag matters on Ubuntu. Without it, a plain check can silently hide phased security updates held back on this particular machine.

This image also arms unattended-upgrades, so security updates are downloaded and applied on a timer without any action from you. You can still run updates on your own schedule:

sudo apt-get update && sudo apt-get -y dist-upgrade

Reboot if a new kernel was installed:

sudo systemctl reboot

Confirm that AppArmor is enforcing, root is locked, and SSH is key-only:

sudo aa-status --enabled && echo "apparmor: enabled"
sudo passwd -S root
sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|pubkeyauthentication) '

Expected output:

apparmor: enabled root L 2009-12-22 -1 -1 -1 -1 permitrootlogin prohibit-password pubkeyauthentication yes passwordauthentication no

OpenSSH on 26.04 reports the setting under its modern name, prohibit-password. Earlier releases printed the legacy spelling without-password for the same policy. Either way, the meaning is the same: root may not authenticate with a password.

The L from passwd -S means the root account is locked.

Confirm that the Azure Linux Agent, cloud-init and time synchronization are healthy and that unattended security updates are armed. Then check your resources:

systemctl is-active walinuxagent 2>/dev/null || systemctl is-active waagent cloud-init --version
systemctl is-enabled apt-daily-upgrade.timer apt-config dump | grep -E 'APT::Periodic::(Update-Package-Lists|Unattended-Upgrade) '
systemctl is-active chrony df -h /

Expected output:

active /usr/bin/cloud-init 26.1-0ubuntu3~26.04.1 enabled APT::Periodic::Update-Package-Lists "1"; APT::Periodic::Unattended-Upgrade "1"; active Filesystem Size Used Avail Use% Mounted on /dev/mapper/ubuntu--vg-ubuntu--lv 27G 2.0G 24G 8% /

The Azure Linux Agent lets Azure provision your SSH key, run extensions and report VM health, so it should always be active.

apt-daily-upgrade.timer being enabled, together with Unattended-Upgrade "1" in the apt periodic config, keeps the machine applying security updates on its own after launch.

This is the reason to choose the LVM image. If you deployed with an OS disk larger than 30 GiB (as in the Step 1 CLI example), the extra space sits unclaimed beyond the LVM partition. You claim it on the running system, with no reboot, no unmount and no downtime.

One thing to know first, measured on this exact image: cloud-init does not claim the space for you. Its growpart module skips LVM roots by design. /var/log/cloud-init.log records '/' SKIPPED: Resizing mapped device (/dev/mapper/ubuntu--vg-ubuntu--lv) skipped as it is not encrypted. So on first boot, the partition, the physical volume and the root volume stay at their shipped 27.5 GiB. That is standard Ubuntu behavior for an LVM root, and it leaves you in control of when and how the space is used.

The chain below claims all of the space into /. Run it as is, or stop after growpart if you would rather keep the space free in the volume group for other volumes.

On 26.04, growpart (cloud-guest-utils 0.33) already extends the physical volume itself when the grown partition carries an LVM PV. The explicit pvresize in the chain is a harmless re-assertion that also covers partitions grown by other tools.

DISK="$(readlink -f /dev/disk/azure/root)"
sudo growpart "${DISK}" 3
sudo pvresize "${DISK}3"
sudo lvextend -l +100%FREE /dev/ubuntu-vg/ubuntu-lv
sudo resize2fs /dev/ubuntu-vg/ubuntu-lv df -h /
FREE=$(sudo vgs --noheadings -o vg_free_count ubuntu-vg | tr -dc '0-9')
PVB=$(sudo pvs --noheadings --units b --nosuffix -o pv_size "${DISK}3" | tr -dc '0-9')
PARTB=$(( $(cat /sys/class/block/$(basename "${DISK}")3/size) * 512 )) if [ "${FREE:-1}" -ne 0 ]; then echo "FAIL: ${FREE} free extents remain in VG ubuntu-vg"; exit 1; fi if [ "$(( PARTB - PVB ))" -gt 8388608 ]; then echo "FAIL: pvresize did not take - partition ${PARTB}B vs physical volume ${PVB}B"; exit 1; fi echo "root volume fully extended: 0 free extents in VG ubuntu-vg, and the physical volume fills the partition"

Expected output on a 64 GiB disk, exactly as produced by this image:

CHANGED: partition=3 start=5244928 old: size=57667584 end=62912511 new: size=128972767 end=134217694 Physical volume "/dev/sda3" changed 1 physical volume(s) resized or updated / 0 physical volume(s) not resized Size of logical volume ubuntu-vg/ubuntu-lv changed from <27.50 GiB (7039 extents) to <61.50 GiB (15743 extents). Logical volume ubuntu-vg/ubuntu-lv successfully resized. resize2fs 1.47.2 (1-Jan-2025) Filesystem at /dev/ubuntu-vg/ubuntu-lv is mounted on /; on-line resizing required old_desc_blocks = 4, new_desc_blocks = 8 The filesystem on /dev/ubuntu-vg/ubuntu-lv is now 16120832 (4k) blocks long. Filesystem Size Used Avail Use% Mounted on /dev/mapper/ubuntu--vg-ubuntu--lv 61G 2.0G 56G 4% / root volume fully extended: 0 free extents in VG ubuntu-vg, and the physical volume fills the partition

resize2fs says on-line resizing required and does it against the mounted root, so the whole chain runs on the live system.

Keep the two checks at the end in your own automation. vg_free_count at 0 proves lvextend claimed everything. The physical volume filling the partition (to within LVM's small metadata gap) proves pvresize actually took. Each catches a failure the other cannot see.

If the disk was already fully claimed, growpart reports NOCHANGE and exits non-zero, lvextend reports that the size already matches, and the final checks still pass. The chain is safe to re-run.

Growing an existing VM later. Enlarge the OS disk first. Deallocate the VM, run az disk update --resource-group <rg> --name <os-disk-name> --size-gb <new-size>, and start the VM again. You can also use the portal's Disks blade. Then run the same chain.

The LVM layout lets you go further than root growth. Attach a data disk and add it to the volume group with sudo pvcreate on the new disk's partition and sudo vgextend ubuntu-vg. Then carve dedicated volumes for data or logs with sudo lvcreate. None of this touches the root filesystem.

The Azure Network Security Group is the control plane for inbound and outbound traffic. It is the first and usually the only place you need to open a port. The image advertises a single inbound port, SSH on 22.

ufw (the Uncomplicated Firewall) is available on this image but left inactive by default. It does not filter traffic, so your NSG rules take effect exactly as written, with no second layer to keep in sync. Confirm what is listening before you open anything:

sudo ss -tlnp

On a fresh machine, the listeners are sshd on port 22 (IPv4 and IPv6) and systemd-resolved on the loopback-only 127.0.0.53:53 and 127.0.0.54:53. The resolver's second loopback stub bypasses its cache. Neither is reachable from outside the machine.

26.04's resolver also ships with LLMNR and multicast DNS disabled, so it opens no off-box discovery ports. Only port 22 is advertised for inbound access, and the Azure NSG governs what is actually reachable from outside.

If your policy requires a host firewall as well, enable the one that is already installed. Add the SSH rule first, before you enable ufw, so you do not lock yourself out:

sudo ufw allow OpenSSH
sudo ufw allow 443/tcp
sudo ufw enable

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

The Ubuntu archive carries the application packages. Search it, then install what you need:

apt-cache search nginx 2>/dev/null | sed -n '1,5p'

Install a package and enable it in the usual way, for example sudo apt-get install -y nginx followed by sudo systemctl enable --now nginx.

To add another administrator, create the account with sudo adduser <name>. Add it to the sudo group with sudo usermod -aG sudo <name>. Then copy your public key into /home/<name>/.ssh/authorized_keys, with mode 600 on the file and mode 700 on the .ssh directory, both owned by that user.

The image ships with no human accounts at all, so azureuser is the only login until you add one:

getent group sudo

Expected output:

sudo:x:27:azureuser