Microsoft Releases Azure Linux 4 ISO Files for Local Testing

Microsoft has posted Azure Linux 4 ISO files on the project’s GitHub page, the first time the Fedora-derived distribution can be installed outside an Azure virtual machine. Both x86-64 and Arm64 images are available, and Microsoft Learn’s official documentation still labels the build as a preview, calling it strictly limited to evaluation and testing purposes.

The release comes with a Fedora upstream that has displaced the older VMware Photon OS, a switch that puts Azure in line with a wider industry walk away from Broadcom-owned VMware.

A Beta Build Out of the Cloud

The ISO files are not where most developers will look first. Releases, the usual home for binaries on a GitHub project, holds only some kernel builds this time around. The Azure Linux team has placed both the x86-64 and Arm64 images further down the page, under a section called Using Azure Linux and inside an ISO Installer subsection, with instructions to verify each file’s checksum and signature before installing. The full file layout lives on the Azure Linux GitHub repository.

The current build reports itself as Four Beta in its banner. Its kernel is 6.18 LTS and its init is systemd 258.4, the same kernel and service manager pair that Microsoft’s documentation lists for the upcoming general release. Microsoft’s What’s New for Azure Linux 4.0 page lists glibc 2.42, OpenSSL 3.5.4, and Python 3.14.3 alongside the kernel, with dnf5 as the package manager that replaces the older tdnf used in earlier releases.

Resource needs are modest on paper. The ISO weighs about 1 GB to download, asks for 1.1 GB of disk space after install, and runs on 359 MB of RAM. The installer is a basic command-line tool that defaults to an LVM configuration with memory ballooning enabled. The Azure Linux 4 distribution operates inside Hyper-V virtual machines on Windows or under QEMU/KVM on Linux. Support for the ISO format itself is community-based, per the project’s GitHub README, with Microsoft directing bug reports through the standard issues list rather than a dedicated channel.

What Ships in the Four Beta Build

Microsoft Learn’s What ships page breaks the build’s version list down into a single table, and a few lines of that table carry most of the practical weight for anyone testing compatibility. Most other components are conventional server-Linux upgrades, and only one swap alters how the same packages get installed.

Most of these lines are routine point upgrades. Python 3.14.3 brings a JIT compiler to scripting, OpenSSL 3.5.4 retires older cipher suites, and glibc 2.42 trims memory allocation paths and string-handling routines. The kernel bump to 6.18 LTS pulls in new hardware drivers, improved Hyper-V integration, and explicit support for GPU and AI accelerators. systemd 258.4 cuts boot times and overhauls service logging for anyone managing the system with traditional init scripts.

The real behavior change is dnf5, a complete rewrite of the package manager that Microsoft Learn says delivers faster dependency resolution and uses less memory than older alternatives. Scripts, Dockerfiles, and CI pipelines that call the older tdnf need updating to dnf5 or dnf before deploying onto a 4.0 system. Anyone treating Azure Linux 4 as a drop-in for Azure Linux 3 needs to audit automation first.

Microsoft Learn also quietly cautions that the new build is not a finished product. The Azure Linux 4.0 documentation warns it is strictly limited to evaluation and testing purposes, and gives the table a FIPS 140-3 row whose entry reads “In progress” with the note that customers who need certified cryptography should stay on a certified release. The two configured repositories mean a very narrow starting palette of packages. Only azurelinux-base and azurelinux-microsoft are enabled by default, both on packages.microsoft.com/azurelinux/. Tools as basic as the less pager and the process viewer htop are not part of the default installation, and The Register’s tester reports that htop is not available to install either. Anaconda runs the installer, with the same text-mode interface long familiar to anyone who has installed Fedora, CentOS, or RHEL from netinstall media.

The Fedora Switch at the Bottom

The most consequential change in Azure Linux 4 is not in the package list. It is the upstream change underneath, where Fedora Linux has replaced VMware Photon OS as the source for most package sources and packaging metadata. The shift shows up in the configuration layer too: Azure Linux 4 moves from .spec files inherited from Photon OS to TOML files, and the project adds an open-source tool called azldev that the Microsoft team uses to render TOML files into RPM spec files automatically. The README frames the architecture as targeted overlays on top of Fedora‘s components, with deviations kept narrow by design.

Reading the upstream as Fedora is misleading. The Register’s tester is explicit: Azure Linux 4 should not be treated as a rebadged Fedora Server, and the two repositories configured by default do not overlap with Fedora’s packaging infrastructure. Mixing the two would break things.

Microsoft has been working toward an in-house Linux toolchain for a while. The Register notes that Microsoft migrated LinkedIn to Azure Linux two years ago, removing CentOS Linux after that distribution went end of life. CentOS Stream replaced CentOS Linux as the official successor. Now that Azure Linux 4 swaps Photon OS for Fedora, Microsoft drops another upstream it depended on for earlier Azure Linux releases.

Microsoft’s Larger Walk Away From VMware

That reduction arrives against a backdrop the rest of the industry has been watching for two years. Broadcom’s 2023 acquisition of VMware reshaped licensing and support terms across a customer base that included some of the world’s largest IT shops, and several of those shops are now publicly working to leave. UK supermarket chain Tesco and US telco T-Mobile have both been in court or in filings describing their break from VMware in unusually detailed terms. The Register covered T-Mobile’s exit on the same day it covered Azure Linux 4’s ISO release, and the pairing is not coincidental in Microsoft’s broader stance. Microsoft’s shift away from Photon OS and into Fedora upstream is one specific piece of a much broader corporate response to Broadcom’s VMware posture. The escalation of public disputes, with detailed court filings rather than private renegotiations, marks the new phase.

T-Mobile’s VMware footprint, as described in filings seen by The Register, is on the same scale as the workloads an entire US carrier network depends on. In a court hearing, T-Mobile’s counsel characterized the company’s VMware installation in unusually candid terms about how it underpins the carrier’s internal network and supports a thousand applications. A separate Broadcom filing says T-Mobile runs VMware across more than 303,000 CPU cores.

The base of the entire internal network and the place where 1,000 applications reside.

T-Mobile’s counsel used those words in a court hearing on the carrier’s exit from VMware, with the words placed in court filings seen by The Register.

The numbers behind the dispute are concrete. 303,000 CPU cores at T-Mobile under VMware. More than 150 VMware products reduced to two subscription-only bundles since Broadcom’s acquisition. Two years of support rights that turn on whether Broadcom’s contracts still apply to products that no longer formally exist.

What T-Mobile wanted, according to the filings, was continuity of support while the carrier migrated elsewhere. The dispute traces back to a VMware deal T-Mobile struck in August 2023, when the telco bought perpetual licenses and two years of support for some of the software, with an option to extend the deal for a third year. When Broadcom acquired VMware, it stopped selling perpetual licenses and standalone support deals, shrinking a product line of more than 150 items to two subscription-only bundles. T-Mobile has sought an injunction to compel Broadcom to keep offering support, and a court granted one that runs through August 3, 2026.

Microsoft does not name Tesco or T-Mobile in its Azure Linux 4 announcement. The direction is the same one the LinkedIn team was tasked with two years ago, removing an end-of-life upstream from a fleet Microsoft controlled. The Azure Linux 4 ISO release gives developers outside Microsoft a chance to do local testing against the same image that will eventually run inside Azure VMs, and the Fedora pivot underneath that image removes one of the older substrate choices that locked Microsoft’s Linux stack into VMware’s release cadence. The visible artifacts (the ISO file, the preview label, the community-based support channel) sit above an upstream switch that does the actual work.

Running It in a Local VM

Microsoft has not built a graphical installer into Azure Linux 4, and the project’s GitHub page gives no indication one is planned. The ISO is set up to be tested in a hypervisor on a developer workstation rather than on bare metal. The README points at Hyper-V on Windows and QEMU/KVM on Linux as the supported targets for local use. Anyone expecting a desktop experience out of the box will not find one.

To bring up an Azure Linux 4 VM locally, the steps are:

1. Visit the Azure Linux GitHub repository and scroll past the project description to the Using Azure Linux heading.
2. Open the ISO Installer subsection and choose the x86-64 or Arm64 image that matches your local machine.
3. Create a new virtual machine in Hyper-V, VirtualBox, QEMU/KVM, or VMware Workstation that boots from the downloaded ISO.
4. Verify the ISO’s checksum and signature, then run the Anaconda-based command-line installer inside the VM and complete the LVM setup that Azure Linux 4 defaults to.

The Azure Linux distribution uses the Anaconda installer, the same text-mode interface that ships with Fedora, CentOS, and RHEL netinstall media. Default installation lays down an LVM configuration with memory ballooning enabled, and the dnf5 package manager is available to add software once the system boots. The handful of community-reported omissions (less and htop, as The Register’s tester noted) come from the narrow two-repository default and not from a configuration bug.

The support path that the README calls out is community-based, not a Microsoft SLA. There is no Azure support ticket route for the ISO format. Microsoft Learn’s lifecycle documentation only commits to long-term support kernels and monthly security updates for Azure Linux 4 once it reaches general availability, and some early reports mention a two-year update cycle that the published lifecycle does not confirm. That mismatch is worth flagging: anyone planning to roll the ISO across a test fleet should track the lifecycle page directly rather than rely on third-party framing. Both x86-64 and Arm64 downloads come from the same GitHub repository, and Microsoft has not announced a specific release date for the general availability milestone.

Why Microsoft Hasn’t Set a Release Date

Microsoft has not named a date for moving Azure Linux 4 out of preview. The Azure Linux GitHub project carries an in-development branch with no version tag for general availability, and the Azure Container Linux sibling repo is the only one with a separate, container-focused life cycle. In the Azure Linux 4 preview, the project sits at the same place LinkedIn’s fleet sat before its migration: a working but unfinished base that Microsoft is testing against Azure’s actual workloads.

The package set is small enough to make that testing narrow. By default, only the azurelinux-base and azurelinux-microsoft repositories are configured, both on packages.microsoft.com/azurelinux/, and Microsoft Learn’s What ships table is the most specific roadmap on offer. The same documentation page gives FIPS 140-3 a status of “In progress” with the note that customers who need certified cryptography should stay on a certified release, which is a polite way of saying that compliance-bound workloads still cannot move. The Azure Linux 4.0 documentation explicitly says the build is not suitable for production use. Bugs, missing packages, and behavior changes before general availability are all on the table.

Microsoft’s published lifecycle gives the future shape. Azure Linux 4 will use long-term support kernels, according to the official lifecycle page, and Microsoft has committed to monthly security updates once the release is generally available. The two-year update cycle you may see mentioned in third-party coverage is not in that document.

Microsoft’s silence on a date is partly the result of how the Azure Linux 4.0 release is staged. The ISO is the first piece a developer outside Azure can boot, and Microsoft’s documentation ties general availability to internal Azure testing rather than to a calendar date. The LinkedIn engineering migration write-up from two years ago is still the most detailed public account of how Microsoft runs Azure Linux at scale. Microsoft’s preview wording is its current signal that the build is good enough to evaluate but not good enough to ship. The official lifecycle commits to LTS kernels and monthly security updates once general availability arrives. Until then, the ISO is for testing, and the Azure Linux team’s preview cadence is the only ongoing source of news.

Frequently Asked Questions

Can Azure Linux 4 be used in production today?

Microsoft’s documentation says no, in plain language. The Azure Linux 4.0 page on Microsoft Learn describes the build as “now in preview” and “strictly limited to evaluation and testing purposes,” and adds that it is “not suitable for production use.” Teams planning to migrate from Azure Linux 3 still need to wait for general availability.

What’s the difference between Azure Linux 4 and Azure Container Linux?

Azure Linux 4 is a general-purpose server distribution that uses dnf5 for traditional package management and is intended for a mix of workloads. Azure Container Linux is a separate Microsoft project, on its own GitHub repository, built specifically to be an immutable container host for the Azure Kubernetes Service. The two run side by side in Microsoft’s Linux lineup.

Will Fedora packages work on Azure Linux 4?

Microsoft and outside testers say no. Azure Linux 4 derives most of its package sources and metadata from Fedora but is not configured to consume Fedora’s repository set. The two default repositories, azurelinux-base and azurelinux-microsoft, both on packages.microsoft.com/azurelinux/, replace Fedora’s mirrors entirely, and the available package selection is much narrower as a result. Common tools such as less and htop are not part of the default installation.

How do I download the Azure Linux 4 ISO?

The ISO files live on the Azure Linux 4 GitHub page rather than in the project’s Releases section. From the GitHub repository, scroll down to the Using Azure Linux heading, expand the ISO Installer subsection, and pick the x86-64 or Arm64 image that matches your machine. The README also asks users to verify each ISO’s checksum and signature before installing.