Ubuntu 20.04 LTS LVM on Azure User Guide

Overview

This guide covers the deployment and configuration of Ubuntu Server 20.04 LTS with an LVM root layout on Microsoft Azure using cloudimg's pre configured virtual machine image from the Azure Marketplace.

Ubuntu is a widely used Linux distribution produced by Canonical. Version 20.04 (Focal Fossa) is a long term support (LTS) release whose standard security maintenance has ended — read the notice below before choosing this image. What makes this image different from the standard Ubuntu Server 20.04 LTS image is the disk layout: the root filesystem lives on an LVM logical volume (ubuntu-vg/ubuntu-lv, the same naming the Ubuntu Server installer's own LVM option uses) on top of a physical volume partition, instead of on a fixed raw partition. That means you can grow the root filesystem online — on the running system, with no reboot and no unmount — and reshape storage later with standard LVM tooling.

End of standard support notice — read this first

Ubuntu 20.04 LTS reached the end of its standard support on 31 May 2025. Two facts follow, and both matter:

• This image is patched to the last packages published in the free Ubuntu archive for 20.04 (archive.ubuntu.com), as of the date the image was captured. The focal archive is still online and apt keeps working against it, but Canonical publishes no further free security updates for 20.04 — over time the machine will carry vulnerabilities that the free archive can never fix.
• Continued security coverage for 20.04 exists, but only through Ubuntu Pro, Canonical's paid subscription, whose Expanded Security Maintenance (ESM) stream covers 20.04 into 2030. ESM packages are delivered only to machines attached to an Ubuntu Pro subscription and are contractually non redistributable, so this image contains no ESM package and no Ubuntu Pro attachment. If your workload needs ongoing security updates, attach your own subscription with sudo pro attach <token> after deployment — or choose the Ubuntu 22.04 LTS LVM or Ubuntu 24.04 LTS LVM image, both of which are inside their free standard maintenance windows on the same LVM layout.

Choose this image when your estate is standardised on 20.04 — a dependency pinned to focal, a fleet mid migration, a vendor appliance certified against it — and you need the LVM layout underneath it. For a fresh deployment with no 20.04 constraint, use a newer LTS.

What's included:

• Ubuntu Server 20.04 LTS with root on LVM: GPT disk with an EFI system partition, a 2 GiB /boot partition, and an LVM physical volume carrying volume group ubuntu-vg with logical volume ubuntu-lv as / (ext4)
• The full LVM and grow toolchain: lvm2, growpart, pvresize, lvextend, resize2fs — the same package set as the standard image, nothing removed
• Patched to the final free archive state for 20.04 at build time
• unattended-upgrades armed — the timers still run against the free archive exactly as on a supported release
• Azure Linux Agent (walinuxagent) and cloud-init for Azure integration
• chrony for NTP time synchronisation
• AppArmor in enforcing mode
• Gen2 Hyper V virtual machine support
• 24/7 cloudimg support

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

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.
• PasswordAuthentication is disabled in the SSH daemon, so every login is by key.
• PermitRootLogin is set to prohibit-password, so root cannot be reached with a password even if one were later set.
• The only key that works is the public key you supply when you create the virtual machine. Azure injects it into azureuser at first boot, so no two machines you launch ever share a secret.
• The machine identity and the SSH host keys are regenerated uniquely on every instance, so no two machines share a host key either.
• AppArmor is left enabled and enforcing, the Ubuntu 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.

Disk size: the image ships as a 30 GiB OS disk with the root volume taking all of its LVM space. If you want a larger root, set a bigger OS disk size at create time (for example 64 GiB) and then grow the root volume online as shown in Step 7 — that is exactly what this image is for.

Step 1: Deploy the Virtual Machine

Option A: Azure Portal

1. Navigate to the Azure Marketplace and search for "Ubuntu 20.04 LTS 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 Azure region
8. Size: Standard_B2s recommended
9. Under Administrator Account, select SSH public key and enter your key
10. Under Inbound Port Rules, allow SSH (port 22)
11. On the Disks tab, set the OS disk size you want (larger than 30 GiB if you plan to grow the root)
12. Click Review + Create, then Create

Option B: Azure CLI

az vm create \
  --resource-group myResourceGroup \
  --name my-ubuntu-lvm-vm \
  --image cloudimg:ubuntu-20-04-lvm:ubuntu2004lvm: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. The extra space is claimed in Step 7 with three LVM commands, online.

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-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, the key you supplied at create time is not the key your client is offering.

Step 3: Confirm the release and the LVM layout

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

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

Expected output:

NAME="Ubuntu"
VERSION="20.04.6 LTS (Focal Fossa)"
ID=ubuntu
PRETTY_NAME="Ubuntu 20.04.6 LTS"
VERSION_ID="20.04"
Linux 5.15.0-1089-azure x86_64
amd64

20.04.6 is the final point release of Ubuntu 20.04, and the 5.15 kernel is the hardware enablement kernel that focal's Azure images track. 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 (kept as a plain partition so the bootloader never depends on LVM activation), and the rest as the LVM physical volume. 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.

Step 4: Check the patch level

The image is patched to the last packages that exist in the free Ubuntu archive for 20.04 at the time of capture. Confirm that nothing further is 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-5.15.0-1089-azure 5.15.0-1089.98~20.04.1

On a release past its end of standard support, pending upgrades: 0 means something narrower than it does on a supported release: the machine has everything the free focal archive will ever publish. It does not mean the machine is patched against vulnerabilities disclosed since — fixes for those exist only in Canonical's paid ESM stream (see the notice at the top of this guide). The image still arms unattended-upgrades with the security origin enabled, so if you attach an Ubuntu Pro subscription the ESM fixes start flowing automatically through the same mechanism; without one the timers simply find nothing new. You can still run updates on your own schedule:

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

To attach an Ubuntu Pro subscription you have purchased (or a free personal token) and start receiving ESM updates:

sudo pro attach <your-token>
sudo apt-get update && sudo apt-get -y dist-upgrade

Step 5: Verify the security posture

Confirm 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 12/22/2009 -1 -1 -1 -1
permitrootlogin without-password
pubkeyauthentication yes
passwordauthentication no

without-password is how OpenSSH reports the prohibit-password setting. Both names mean the same thing: root may not authenticate with a password. The L from passwd -S means the root account is locked.

Step 6: Verify Azure integration and update plumbing

Confirm the Azure Linux Agent, cloud-init and time synchronisation are healthy, that the update timers are armed, and 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 24.4.1-0ubuntu0~20.04.3
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  1.8G   24G   8% /

The Azure Linux Agent is what 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 update mechanism live — against the frozen free archive as shipped, and against ESM too the moment you attach an Ubuntu Pro subscription.

Step 7: Grow the root filesystem online

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 is sitting unclaimed beyond the LVM partition, and you claim it on the running system — no reboot, no unmount, 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 behaviour for an LVM root, and it leaves you in control of when and how the space is used. The chain below claims all of it into /; run it as is, or stop after pvresize if you would rather keep the space free in the volume group for other volumes.

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=62912512 new: size=128972767 end=134217695
  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.45.5 (07-Jan-2020)
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  1.8G   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 — the whole chain runs on the live system. The two checks at the end are worth keeping in your own automation: vg_free_count at 0 proves lvextend claimed everything, and 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. On this image's growpart (0.31), growing the partition does not grow the physical volume as a side effect, so a chain that skips pvresize leaves the new space invisible to LVM while the extent count still reads 0 — exactly the dead state the second check exists to catch.

If the disk was already fully claimed, growpart reports NOCHANGE and exits non zero, lvextend reports 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, az disk update --resource-group <rg> --name <os-disk-name> --size-gb <new-size>, start the VM — or use the portal's Disks blade), then run the same chain. The LVM layout also 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 — all without touching the root filesystem.

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. The image advertises a single inbound port, SSH on 22.

ufw (the Uncomplicated Firewall) is available on this image but left inactive by default, so it is not filtering traffic and 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. Only port 22 is advertised for inbound access, and the Azure NSG is what 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 enabling, 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.

Step 9: Install software

The free focal archive still carries every application package 20.04 ever shipped, at its final published version. 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. Remember the support posture from the top of this guide applies to everything you install from the archive: the package versions are frozen where standard support ended, unless you attach Ubuntu Pro.

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 and the .ssh directory mode 700, 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

Common Use Cases

• Estates standardised on Ubuntu 20.04 that need LVM managed disks and an online root grow
• Workloads whose storage needs will grow — extend the root online instead of rebuilding the VM
• Servers that will gain dedicated volumes later, for data, logs or applications
• Controlled migrations that need a reproducible 20.04 base while workloads move to a newer LTS

Troubleshooting

Cannot connect via SSH

1. Verify the VM is in Running state in the Azure Portal
2. Check that port 22 is allowed in the Network Security Group
3. Ensure you are using the correct username: azureuser
4. Verify your SSH key matches the one you supplied at create time. Password login is disabled by design, so a wrong key cannot fall back to a password prompt.

To see which key your client is actually offering, run ssh -v azureuser@<vm-ip> from your workstation and look for the Offering public key lines.

df shows 27G on a bigger disk

That is the expected state before Step 7 has been run: cloud-init deliberately does not grow an LVM root, so a VM deployed on a 64 GiB disk boots with the shipped 27.5 GiB root volume until you claim the space. Run the Step 7 chain — it is online and takes seconds.

growpart says NOCHANGE

The partition already fills the disk. growpart exits non zero on NOCHANGE, which is informational, not an error — if you expected new space, confirm the OS disk resize actually happened (az disk show --query diskSizeGb) and that the VM was restarted after an offline disk resize.

Azure agent not running

sudo systemctl status walinuxagent
sudo systemctl enable --now walinuxagent

Package manager issues

Refresh the metadata cache first:

sudo apt-get update

If repositories are unreachable, check DNS resolution. getent is always present and resolves through the same system resolver:

getent hosts archive.ubuntu.com

The focal package archive remains online after the end of standard support, so apt-get update succeeding against it is the expected state — it just no longer receives new security uploads outside the paid ESM stream.

A service is blocked and the logs mention AppArmor

AppArmor is enforcing on this image. One denial is expected and harmless: during early boot, cloud-init's Azure datasource runs a short lived dhclient probe with /bin/true as its script, and the stock dhclient AppArmor profile denies that exec. It appears up to twice per boot (profile="/{,usr/}sbin/dhclient" name="/usr/bin/true", once from dhclient and once from its isc-worker helper), is inherited from the stock Ubuntu 20.04 Azure base, and has no effect on provisioning or networking. Beyond that probe, a healthy machine has no denials:

sudo journalctl -k --no-pager | awk '/apparmor/ && /DENIED/ && !/sbin\/dhclient/{n++} END{print "denials beyond the known first-boot dhclient probe: " n+0}'

Expected output:

denials beyond the known first-boot dhclient probe: 0

Important Notes

Ubuntu is free and open source. It is not covered by a single licence: it is a distribution assembled from thousands of independently packaged components, each carrying its own terms, including the GPL, LGPL, MIT, BSD, Apache 2.0 and MPL. Every package's terms are readable with dpkg -s <package> and under /usr/share/doc/<package>/copyright. No subscription or licence key is required to run this image; Ubuntu Pro is an optional Canonical subscription that is neither included nor required here — though, as the notice at the top of this guide explains, after 20.04's end of standard support on 31 May 2025 it is the only route to further Canonical security updates, and its ESM packages are non redistributable, so this image ships without them and is patched to the final free archive state instead.

Ubuntu is a trademark of Canonical Ltd. The name is used here nominatively, only to identify the distribution this image contains. cloudimg is not affiliated with, endorsed by or sponsored by Canonical Ltd.

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