Linux on Azure at Microsoft Ignite 2025: What’s New, What to Attend, and Where to Find Us
Microsoft Ignite 2025 is almost here, and we’re heading back to San Francisco from November 17-21 with a full digital experience for those joining online. Every year, Ignite brings together IT pros, developers, security teams, and technology leaders from around the world to explore the future of cloud, AI, and infrastructure. This year, Linux takes center stage in a big way. From new security innovations in Azure Linux to deeper AKS modernization capabilities and hands-on learning opportunities, Ignite 2025 is packed with content for anyone building, running, or securing Linux-based workloads in Azure. Below is your quick guide to the biggest Linux announcements and the must-see sessions. Major Linux Announcements at Ignite 2025 Public Preview: Built-in CIS Benchmarks for Azure Endorsed Linux Distributions CIS Benchmarks are now integrated directly into Azure Machine Configuration, giving you automated and customizable compliance monitoring across Azure, hybrid, and on-prem environments. This makes it easier to continuously govern your Linux estate at scale with no external tooling required. Public Preview: Azure Linux OS Guard Azure Linux OS Guard introduces a hardened, immutable Linux container host for AKS with FIPS mode enforced by default, a reduced attack surface, and tight AKS integration. It is ideal for highly regulated or sensitive workloads and brings stronger default security with less operational complexity. General Availability: Pod Sandboxing for AKS (Kata Containers) Pod Sandboxing with fully managed Kata Containers is now GA, delivering VM-level isolation for AKS workloads. This provides stronger separation of CPU, memory, and networking and is well-suited for multi-tenant applications or organizations with strict compliance boundaries. Linux Sessions at Ignite Whether you are optimizing performance, modernizing with containers, or exploring new security scenarios, there is something for every Linux practitioner. Breakout Sessions Session Code Session Name Date and Time (PST) BRK143 Optimizing performance, deployments, and security for Linux on Azure Thu Nov 20, 1:00 PM to 1:45 PM BRK144 Build, modernize, and secure AKS workloads with Azure Linux Wed Nov 19, 1:30 PM to 2:15 PM BRK104 From VMs and containers to AI apps with Azure Red Hat OpenShift Thu Nov 20, 8:30 AM to 9:15 AM BRK137 Nasdaq Boardvantage: AI-driven governance on PostgreSQL and AI Foundry Wed Nov 19, 11:30 AM to 12:15 PM Theatre Sessions Session Code Session Name Date and Time (PST) THR712 Hybrid workload compliance from policy to practice on Azure Tue Nov 18, 3:15 PM to 3:45 PM THR701 From Container to Node: Building Minimal-CVE Solutions with Azure Linux Wed Nov 19, 3:30 PM to 4:00 PM Hands-on Lab Lab 505: Fast track your Linux and PostgreSQL migration with Azure Migrate Tue Nov 18, 4:30 PM to 5:45 PM Wed Nov 19, 3:45 PM to 5:00 PM Thu Nov 20, 9:00 AM to 10:15 AM This interactive lab helps you assess, plan, and execute Linux and PostgreSQL migrations at scale using Azure Migrate’s end-to-end tooling. Meet the Linux on Azure Team at Ignite If you are attending in person, come say hello. Visit the Linux on Azure Expert Meetup stations inside the Microsoft Hub. You can ask questions directly to Microsoft’s Linux engineering and product experts, explore demos across Azure Linux, compliance, and migration, and get recommendations tailored to your workloads. We always love meeting customers and partners.Dalec: Declarative Package and Container Builds
Build once, deploy everywhere. From a single YAML specification, Dalec produces native Linux packages (RPM, DEB) and container images - no Dockerfiles, no complex RPM spec or control files, just declarative configuration. Dalec, a Cloud Native Computing Foundation (CNCF) Sandbox project, is a Docker BuildKit frontend that enables users to build system packages and container images from declarative YAML specifications. As a BuildKit frontend, Dalec integrates directly into the Docker build process, requiring no additional tools beyond Docker itself.Introducing Image Customizer for Azure Linux
We are excited to release Image Customizer, an open-source tool, built and maintained by the Azure Linux team. Image Customizer lets you customize well-tested existing Azure Linux images for any scenario in just minutes. Already trusted by first party teams like LinkedIn, Azure Frontdoor, and Azure Nexus in production, this tool is designed to make image customization simple, reliable, and fast. With full dm-verity support for enhanced security, it also supports customization of Azure Linux with OS Guard images. Unlike VM-based image customization, Image Customizer directly modifies the image without booting a VM using a chroot-based approach, making customization faster, more reliable, and easier to integrate into existing workflows. ✨ Get Image Customizer here ✨ Explore our documentation here. Why Choose Image Customizer? Direct, Reliable Customization Build on top of bootable, tested, and supported base images. Lower overhead and fewer side effects by avoiding VM boot. No need to rely on the Azure Linux Toolkit. Previously, building from scratch meant your image may fail to boot sometimes. Image Customizer reduces that risk. Clean and Lightweight Minimal dependencies for a streamlined setup (for example, no SSH required). You only need to invoke one command to run Image Customizer. It is available as a container with all its dependencies bundled for easy integration into CI/CD pipelines. Versatile and Powerful Supported input formats: vhd, vhdx, qcow2, PXE bootable artifacts, raw and iso created by Image Customizer. Supported output formats: vhd, vhd-fixed, vhdx, qcow2, raw, iso, and cosi. Perform a wide range of operations: add/remove/update packages, add files and directories, create/update users, enable/disable services, customize partitions, image history, dm-verity and more. Full list of supported operations can be found here. Cross-Platform Compatibility Tested and verified to work on Ubuntu 22.04, Azure Linux 3.0 and WSL2 (Windows Subsystem for Linux). While officially tested on these platforms, Image Customizer will likely work on other Linux distributions as well. Consistent and Predictable Builds Use --package-snapshot-time or snapshotTime to filter packages by publication timestamp, ensuring only packages available at that point in time are considered. This prevents unexpected changes from newer package versions when reusing configuration files across time. Getting Started with Image Customizer To use Image Customizer, you’ll need a configuration file that describes the changes you want to make, using the Declarative API provided by Image Customizer. Next, select a base Azure Linux image as your foundation. With these two pieces in hand, you’re ready to run Image Customizer. The easiest way is to use the Image Customizer container, which comes pre-packaged with all necessary dependencies and is recommended for most users. Alternatively, you can use the standalone executable binary if that better fits your workflow. In just a few minutes, Image Customizer will generate a modified Azure Linux image tailored to your needs. This process is designed to be repeatable and user-friendly, making it easy to add packages, files, users, make partition changes, and much more. To help you get started, we have a Quick Start guide that walks you through your first customization step by step. For those who want to explore further, comprehensive API documentation is available, covering both Command-line usage and Configuration options. Upcoming Community Call Join our upcoming community call to learn more about using Image Customizer and see a live demo. We’ll cover best practices, advanced scenarios, and answer any questions you may have. Date & Time: September 25 th , 2025 at 8:00AM PST Teams Link: Azure Linux - External Community Call | Meeting-Join | Microsoft Teams Community Call Schedule: https://learn.microsoft.com/en-us/azure/azure-linux/support-help#stay-connected-with-azure-linux Help and Feedback If you’d like to report bugs, request features, or contribute to the tool, you can do so directly through our azure-linux-image-tools GitHub repo. We welcome feedback and contributions from the community! Acknowledgements A huge thank you (in no order) to our Image Customizer team ─ Adit Jha, Brian Telfer, Chris Gunn, Deepu Thomas, Elaine Zhao, George Mileka, Himaja Kesari, Jim Perrin, Jiri Appl, Lanze Liu, Roaa Sakr, Kavya Nagalakunta and Vince Perri.
AKS Automatic with Azure Linux
Earlier today Microsoft announced that AKS Automatic is officially Generally Available (GA) on Azure Kubernetes Service (AKS). AKS Automatic enables organizations to build, deploy, and scale applications on Kubernetes with enhanced efficiency and minimal operational overhead. By default, AKS Automatic runs on Azure Linux, providing a secure, performant, and Azure-optimized foundation for modern Kubernetes workloads. What is AKS Automatic? AKS Automatic significantly simplifies the managed Kubernetes experience for developers and platform teams. Unlike AKS Standard, AKS Automatic handles cluster setup—including node management, scaling, security, networking, and preconfigured settings aligned with AKS well-architected recommendations. How does Azure Linux support AKS Automatic? AKS Automatic leverages Azure Linux as the default operating system for all user and system node pools. This integration ensures that your clusters benefit from built-in best practices and security safeguards at the OS level. Collectively, AKS Automatic and Azure Linux address key needs from Kubernetes customers today: CVE Management: Azure Linux includes only the essential packages required for Kubernetes and container workloads. This results in fewer patches, reduced update frequency, and a minimized attack surface. AKS Automatic further enhances image security with a built-in image cleaner that automatically removes unused images with known vulnerabilities. Secure by Default: AKS Automatic clusters come with hardened default security configurations. Azure Linux reinforces this with a hardened kernel tuned for Azure, secure-by-default principles, and compliance certifications including FIPS and FedRAMP. It also passes all CIS Level 1 benchmarks by default, making it the only AKS-supported distribution to do so. Resiliency: AKS Automatic automatically patches nodes and cluster components while respecting planned maintenance schedules. Every update is rigorously tested by the Azure Linux and AKS teams—through unit and Kubernetes end-to-end testing—to prevent regressions. The reduced package footprint in the Azure Linux node image further minimizes the risk of disruption. Performance: AKS Automatic’s built-in node management, combined with Azure Linux’s reduced image footprint, ensures that your clusters operate efficiently by default. Azure Linux clusters consume less disk and memory and deliver faster performance across key AKS operations such as cluster creation, upgrades, scaling, deletion, node provisioning, and pod startup. Tooling: AKS Automatic clusters are preconfigured with monitoring, scaling, security, and networking tools. All current and future AKS extensions, add-ons, and open-source projects are fully supported on Azure Linux. Unified Support: With AKS Automatic and Azure Linux, Microsoft provides end-to-end support for the entire Kubernetes stack—simplifying troubleshooting and accelerating resolution. Together, AKS Automatic and Azure Linux empower organizations to innovate faster on Kubernetes with reduced operational complexity. How to get started? With AKS Automatic you can go from a container image to a deployed application that adheres to best practices within minutes. Follow this tutorial to get started deploying an AKS Automatic cluster today.Azure Linux 3.0 Achieves Level 1 CIS Benchmark Certification
We’re excited to announce that Azure Linux 3.0 has successfully passed the Level 1 Center for Internet Security (CIS) benchmarks, reinforcing our commitment to delivering a secure and compliant platform for customers running Linux workloads on Azure Kubernetes Service (AKS). What is CIS? The Center for Internet Security is a nonprofit entity whose mission is to identify, develop, validate, promote, and sustain best practice solutions for cyber defense. It draws on the expertise of cybersecurity and IT professionals from government, business, and academia from around the world. To develop standards and best practices, including CIS benchmarks, controls, and hardened images, they follow a consensus decision-making model. CIS benchmarks are configuration baselines and best practices for securely configuring a system. CIS controls map to many established standards and regulatory frameworks, including the NIST Cybersecurity Framework (CSF) and NIST SP 800-53, the ISO 27000 series of standards, PCI DSS, HIPAA, and others. Each benchmark undergoes two phases of consensus review. The first occurs during initial development when experts convene to discuss, create, and test working drafts until they reach consensus on the benchmark. During the second phase, after the benchmark has been published, the consensus team reviews the feedback from the internet community for incorporation into the benchmark. CIS benchmarks provide two levels of security settings: Level 1 recommends essential basic security requirements that can be configured on any system and should cause little or no interruption of service or reduced functionality. Level 2 recommends security settings for environments requiring greater security that could result in some reduced functionality. What does this mean for Azure Linux 3.0? By meeting Level 1 requirements, Azure Linux 3.0 ensures that essential security controls are in place—helping organizations meet regulatory compliance and protect against common threats, without sacrificing performance or agility. For security and compliance-focused customers, this milestone means you can confidently deploy and scale your Linux-based applications on AKS, knowing that your foundation aligns with industry’s best practices. Azure Linux 3.0’s compliance with CIS Level 1 benchmarks support your efforts to achieve and maintain rigorous security postures, whether you’re subject to regulatory frameworks or following internal policies. How can customers try it out? We remain dedicated to making security simple. All Azure Linux 3.0 nodes on an AKS cluster will meet the Level 1 CIS benchmarks – no extra flags or parameters. Resources Visit the CIS Benchmark documentation to read a detailed list of benchmarks: Center for Internet Security (CIS) Benchmarks - Microsoft Compliance | Microsoft Learn.Azure Linux with OS Guard: Immutable Container Host with Code Integrity and Open Source Transparency
Azure Linux OS Guard brings next-level security to Kubernetes with enforced immutability, provenance, and policy controls. Built on a trusted foundation, it’s already powering Microsoft services and is fully open source.Azure Linux Now Supports AKS Long-Term Support (LTS) Starting with Kubernetes v1.28+
What’s New Managing Kubernetes upgrades can be a challenge for many organizations. The fast-paced release cycle requires frequent cluster updates, which can be time-consuming, carry operational risks, and require repeated validation of workloads and infrastructure. To address this, in April of this year, Azure Kubernetes Service (AKS) introduced Long-Term Support (LTS) on every AKS version — beginning with Kubernetes version 1.28. With AKS LTS, every community-released version of Kubernetes receives an extended support window of an additional year, giving customers more time to test, validate, and adopt new versions at a pace that suits their business needs. The Azure Linux team is excited to announce that Azure Linux now also supports AKS LTS starting with Kubernetes version 1.28 and above. This means you can now pair a stable, enterprise-grade node operating system with the extended lifecycle benefits of AKS LTS — providing a consistent, secure, and well-maintained platform for your container workloads. Benefits of Azure Linux with your AKS LTS Clusters Secure by Design: Azure Linux is built from source using Microsoft’s trusted pipelines, with a minimal package set that reduces the attack surface. It is FIPS-compliant and meets CIS Level 1 benchmarks. Operational Stability: With AKS LTS, each version is supported for two years, reducing upgrade frequency and providing a predictable, stable platform for mission-critical workloads. Reliable Updates: Every package update is validated by both the Azure Linux and AKS teams, running through a full suite of tests to prevent regressions and minimize disruptions. Broad Compatibility: Azure Linux supports AKS extensions, add-ons, and open-source projects. It works seamlessly with existing Linux based containers and includes the upstream containerd runtime. Advanced Isolation: It is the only OS on AKS that supports pod sandboxing, enabling compute isolation between pods for enhanced security. Seamless Migration: Customers can migrate from other distributions to Azure Linux nodepools in-place without recreating clusters, simplifying the process. Getting Started Getting started with Azure Linux on AKS LTS is simple and can be done with a single command. See full documentation on getting started with AKS Long-term Support here. Please note that when enabling LTS on a new Azure Linux cluster you will need to specify --os-sku AzureLinux. Considerations LTS is available on the Premium tier. Refer to the Premium tier pricing for more information. Some add-ons and features might not support Kubernetes versions outside upstream community support windows. View unsupported add-ons and features here. Please note Azure Linux 2.0 is the default node OS for AKS versions v1.27 to v1.31 during both Standard and Long-Term Support. However, Azure Linux 2.0 will reach End of Life during the LTS period of AKS v1.28–v1.31. To maintain support and security updates, customers running Azure Linux 2.0 on AKS v1.28–v1.31 LTS are requested to migrate to Azure Linux 3.0 by November 2025. Azure Linux 3.0 has been validated to support AKS Kubernetes v1.28–v1.31. Before Azure Linux 2.0 goes EoL, AKS will offer a feature to facilitate an in-place migration from Azure Linux 2.0 to 3.0 via a node pool update command. For feature availability and updates, see GitHub issue. After November 2025 Azure Linux 2.0 will no longer receive updates, security patches, or support, which may put your systems at risk. AKS version Azure Linux version during AKS Standard Support Azure Linux version during AKS Long-Term Support 1.27 Azure Linux 2.0 Azure Linux 2.0 1.28 - 1.31 Azure Linux 2.0 Azure Linux 2.0 (migrate to 3.0 by Nov 2025) 1.32+ Azure Linux 3.0 Azure Linux 3.0 For more information on the Azure Linux Container Host support lifecycle see here. How to Keep in Touch with the Azure Linux Team: For updates, feedback, and feature requests related to Azure Linux, there are a few ways to stay connected to the team: We have a public community call every other month for Azure Linux users to come together to ask questions, share learnings, and get updates. Join the next community call on July 24 th at 8AM PST: here Partners with support questions can reach out to AzureLinuxISV@microsoft.comAzure Image Testing for Linux (AITL)
As cloud and AI evolve at an unprecedented pace, the need to deliver high-quality, secure, and reliable Linux VM images has never been more essential. Azure Image Testing for Linux (AITL) is a self-service validation tool designed to help developers, ISVs, and Linux distribution partners ensure their images meet Azure’s standards before deployment. With AITL, partners can streamline testing, reduce engineering overhead, and ensure compliance with Azure’s best practices, all in a scalable and automated manner. Let’s explore how AITL is redefining image validation and why it’s proving to be a valuable asset for both developers and enterprises. Before AITL, image validation was largely a manual and repetitive process, engineers were often required to perform frequent checks, resulting in several key challenges: Time-Consuming: Manual validation processes delayed image releases. Inconsistent Validation: Each distro had different methods for testing, leading to varying quality levels. Limited Scalability: Resource constraints restricted the ability to validate a broad set of images. AITL addresses these challenges by enabling partners to seamlessly integrate image validation into their existing pipelines through APIs. By executing tests within their own Azure subscriptions prior to publishing, partners can ensure that only fully validated, high-quality Linux images are promoted to production in the Azure environment. How AITL Works? AITL is powered by LISA, which is a test framework and a comprehensive opensource tool contains 400+ test cases. AITL provides a simple, yet powerful workflow run LISA test cases: Registration: Partners register their images in AITL’s validation framework. Automated Testing: AITL runs a suite of predefined validation tests using LISA. Detailed Reporting: Developers receive comprehensive results highlighting compliance, performance, and security areas. All test logs are available to access. Self-Service Fixes: Any detected issues can be addressed by the partner before submission, eliminating delays and back-and-forth communication. Final Sign-Off: Once tests pass, partners can confidently publish their images, knowing they meet Azure’s quality standards. Benefits of AITL AITL is a transformative tool that delivers significant benefits across the Linux and cloud ecosystem: Self-Service Capability: Enables developers and ISVs to independently validate their images without requiring direct support from Microsoft. Scalable by Design: Supports concurrent testing of multiple images, driving greater operational efficiency. Consistent and Standardized Testing: Offers a unified validation framework to ensure quality and consistency across all endorsed Linux distributions. Proactive Issue Detection: Identifies potential issues early in the development cycle, helping prevent costly post-deployment fixes. Seamless Pipeline Integration: Easily integrates with existing CI/CD workflows to enable fully automated image validation. Use Cases for AITL AITL designed to support a diverse set of users across the Linux ecosystem: Linux Distribution Partners: Organizations such as Canonical, Red Hat, and SUSE can validate their images prior to publishing on the Azure Marketplace, ensuring they meet Azure’s quality and compliance standards. Independent Software Vendors (ISVs): Companies providing custom Linux Images can verify that their custom Linux-based solutions are optimized for performance and reliability on Azure. Enterprise IT Teams: Businesses managing their own Linux images on Azure can use AITL to validate updates proactively, reducing risk and ensuring smooth production deployments. Current Status and Future Roadmap AITL is currently in private preview, with five major Linux distros and select ISVs actively integrating it into their validation workflows. Microsoft plans to expand AITL’s capabilities by adding: Support for Private Test Cases: Allowing partners to run custom tests within AITL securely. Kernel CI Integration: Enhancing low-level kernel validation for more robust testing and results for community. DPDK and Specialized Validation: Ensuring network and hardware performance for specialized SKU (CVM, HPC) and workloads How to Get Started? For developers and partners interested in AITL, following the steps to onboard. Register for Private Preview AITL is currently hidden behind a preview feature flag. You must first register the AITL preview feature with your subscription so that you can then access the AITL Resource Provider (RP). These are one-time steps done for each subscription. Run the “az feature register” command to register the feature: az feature register --namespace Microsoft.AzureImageTestingForLinux --name JobandJobTemplateCrud Sign Up for Private Preview – Contact Microsoft’s Linux Systems Group to request access. Private Preview Sign Up To confirm that your subscription is registered, run the above command and check that properties.state = “Registered” Register the Resource Provider Once the feature registration has been approved, the AITL Resource Provider can be registered by running the “az provider register” command: az provider register --namespace Microsoft.AzureImageTestingForLinux *If your subscription is not registered to Microsoft.Compute/Network/Storage, please do so. These are also prerequisites to using the service. This can be done for each namespace (Microsoft.Compute, Microsoft.Network, Microsoft.Storage) through this command: az provider register --namespace Microsoft.Compute Setup Permissions The AITL RP requires a permission set to create test resources, such as the VM and storage account. The permissions are provided through a custom role that is assigned to the AITL Service Principal named AzureImageTestingForLinux. We provide a script setup_aitl.py to make it simple. It will create a role and grant to the service principal. Make sure the active subscription is expected and download the script to run in a python environment. https://raw.githubusercontent.com/microsoft/lisa/main/microsoft/utils/setup_aitl.py You can run the below command: python setup_aitl.py -s "/subscriptions/xxxx" Before running this script, you should check if you have the permission to create role definition in your subscription. *Note, it may take up to 20 minutes for the permission to be propagated. Assign an AITL jobs access role If you want to use a service principle or registration application to call AITL APIs. The service principle or App should be assigned a role to access AITL jobs. This role should include the following permissions: az role definition create --role-definition '{ "Name": "AITL Jobs Access Role", "Description": "Delegation role is to read and write AITL jobs and job templates", "Actions": [ "Microsoft.AzureImageTestingForLinux/jobTemplates/read", "Microsoft.AzureImageTestingForLinux/jobTemplates/write", "Microsoft.AzureImageTestingForLinux/jobTemplates/delete", "Microsoft.AzureImageTestingForLinux/jobs/read", "Microsoft.AzureImageTestingForLinux/jobs/write", "Microsoft.AzureImageTestingForLinux/jobs/delete", "Microsoft.AzureImageTestingForLinux/operations/read", "Microsoft.Resources/subscriptions/read", "Microsoft.Resources/subscriptions/operationresults/read", "Microsoft.Resources/subscriptions/resourcegroups/write", "Microsoft.Resources/subscriptions/resourcegroups/read", "Microsoft.Resources/subscriptions/resourcegroups/delete" ], "IsCustom": true, "AssignableScopes": [ "/subscriptions/01d22e3d-ec1d-41a4-930a-f40cd90eaeb2" ] }' You can create a custom role using the above command in the cloud shell, and assign this role to the service principle or the App. All set! Please go through a quick start to try AITL APIs. Download AITL wrapper AITL is served by Azure management API. You can use any REST API tool to access it. We provide a Python wrapper for better experience. The AITL wrapper is composed of a python script and input files. It calls “az login” and “az rest” to provide similar experience like the az CLI. The input files are used for creating test jobs. Make sure az CLI and python 3 are installed. Clone LISA code, or only download files in the folder. lisa/microsoft/utils/aitl at main · microsoft/lisa (github.com). Use the command below to check the help text. python -m aitl job –-help python -m aitl job create --help Create a job Job creation consists of two entities: A job template and an image. The quickest way to get started with the AITL service is to create a Job instance with your job template properties in the request body. Replace placeholders with the real subscription id, resource group, job name to start a test job. This example runs 1 test case with a marketplace image using the tier0.json template. You can create a new json file to customize the test job. The name is optional. If it’s not provided, AITL wrapper will generate one. python -m aitl job create -s {subscription_id} -r {resource_group} -n {job_name} -b ‘@./tier0.json’ The default request body is: { "location": "westus3", "properties": { "jobTemplateInstance": { "selections": [ { "casePriority": [ 0 ] } ] } } } This example runs the P0 test cases with the default image. You can choose to add fields to the request, such as image to test. All possible fields are described in the API Specification – Jobs section. The “location” property is a required field that represents the location where the test job should be created, it doesn’t affect the location of VMs. AITL supports “westus”, “westus2”, or “westus3”. The image object in the request body json is where the image type to be used for testing is detailed, as well as the CPU architecture and VHD Generation. If the image object is not included, LISA will pick a Linux marketplace image that meets the requirements for running the specified tests. When an image type is specified, additional information will be required based on the image type. Supported image types are VHD, Azure Marketplace image, and Shared Image Gallery. - VHD requires the SAS URL. - Marketplace image requires the publisher, offer, SKU, and version. - Shared Image Gallery requires the gallery name, image definition, and version. Example of how to include the image object for shared image gallery. (<> denotes placeholder): { "location": "westus3", “properties: { <...other properties from default request body here>, "image": { "type": "shared_gallery", "architecture": "x64", "vhdGeneration": 2, "gallery": "<Example: myAzureComputeGallery>", "definition": "<Example: myImage1>", "version": "<Example: 1.0.1>" } } } Check Job Status & Test Results A job is an asynchronous operation that is updated throughout the job’s lifecycle with its operation and ongoing tests status. A job has 6 provisioning states – 4 are non-terminal states and 2 are terminal states. Non-terminal states represent ongoing operation stages and terminal states represent the status at completion. The job’s current state is reflected in the `properties.provisioningState` property located in the response body. The states are described below: Operation States State Type Description Accepted Non-Terminal state Initial ARM state describing the resource creation is being initialized. Queued Non-Terminal state The job has been queued by AITL to run LISA using the provided job template parameters. Scheduling Non-Terminal state The job has been taken off the queue and AITL is preparing to launch LISA. Provisioning Non-Terminal state LISA is creating your VM within your subscription using the default or provided image. Running Non-Terminal state LISA is running the specified tests on your image and VM configuration. Succeeded Terminal state LISA completed the job run and has uploaded the final test results to the job. There may be failed test cases. Failed Terminal state There was a failure during the job’s execution. Test results may be present and reflect the latest status for each listed test. Test results are updated in near real-time and can be seen in the ‘properties.results’ property in the response body. Results will begin to get updated during the “Running” state and the final set of result updates will happen prior to reaching a terminal state (“Completed” or “Failed”). For a complete list of possible test result properties, go to the API Specification – Test Results section. Run below command to get detailed test results. python -m aitl job get -s {subscription_id} -r {resource_group} -n {job_name} The query argument can format or filter results by JMESquery. Please refer to help text for more information. For example, List test results and error messages. python -m aitl job get -s {subscription_id} -r {resource_group} -n {job_name} -o table -q 'properties.results[].{name:testName,status:status,message:message}' Summarize test results. python -m aitl job get -s {subscription_id} -r {resource_group} -n {job_name} -q 'properties.results[].status|{TOTAL:length(@),PASSED:length([?@==`"PASSED"`]),FAILED:length([?@==`"FAILED"`]),SKIPPED:length([?@==`"SKIPPED"`]),ATTEMPTED:length([?@==`"ATTEMPTED"`]),RUNNING:length([?@==`"RUNNING"`]),ASSIGNED:length([?@==`"ASSIGNED"`]),QUEUED:length([?@==`"QUEUED"`])}' Access Job Logs To access logs and read from Azure Storage, the AITL user must have “Storage Blob Data Owner” role. You should check if you have the permission to create role definition in your subscription, likely with your administrator. For information on this role and instructions on how to add this permission, see this Azure documentation. To access job logs, send a GET request with the job name and use the logUrl in the response body to retrieve the logs, which are stored in Azure storage container. For more details on interpreting logs, refer to the LISA documentation on troubleshooting test failures. To quickly view logs online (note that file size limitations may apply), select a .log Blob file and click "edit" in the top toolbar of the Blob menu. To download the log, click the download button in the toolbar. Conclusion AITL represents a forward-looking approach to Linux image validation bringing automation, scalability, and consistency to the forefront. By shifting validation earlier in the development cycle, AITL helps reduce risk, accelerate time to market, and ensure a reliable, high-quality Linux experience on Azure. Whether you're a developer, a Linux distribution partner, or an enterprise managing Linux workloads on Azure, AITL offers a powerful way to modernize and streamline your validation workflows. To learn more or get started with AITL or more details and access to AITL, reach out to Microsoft Linux Systems GroupCanonical Ubuntu 20.04 LTS Reaching End of Standard Support
We’re announcing the upcoming end of standard support for Ubuntu 20.04 LTS (Focal Fossa) on 31 May 2025, as we focus on delivering a more secure and optimized Linux experience. Originally released in April 2020, Ubuntu 20.04 LTS introduced key enhancements like improved UEFI Secure Boot and broader Kernel Livepatch coverage, strengthening security on Azure. You can continue using your existing virtual machines, but after this date, security, features, and maintenance updates will no longer be provided by Canonical, which may impact system security and reliability. Recommended action: It’s important to act before 31 May 2025 to ensure you’re on a supported operating system. Microsoft recommends either migrating to the next Ubuntu LTS release or upgrading to Ubuntu Pro to gain access to expanded security and maintenance from Canonical. Upgrading to Ubuntu 22.04 LTS or Ubuntu 24.04 LTS Transitioning to the latest operating system, such as Ubuntu 24.04 LTS, is important for performance, hardware enablement, new technology benefits, and is recommended for new instances. It may be a complex process for existing deployments and should be properly scoped and tested with your workloads. While there’s no direct upgrade path from Ubuntu 20.04 LTS to Ubuntu 24.04 LTS, you can directly upgrade to Ubuntu 22.04 LTS, and then to Ubuntu 24.04 LTS, or directly install Ubuntu 24.04 LTS. See the Ubuntu Server upgrade guide for more information. Ubuntu Pro – Expanded Security Maintenance to 2030 Ubuntu Pro includes security patching for all Ubuntu packages due to Expanded Security Maintenance (ESM) for Infrastructure and Applications and optional 24/7 phone and ticket support. Ubuntu Pro 20.04 LTS will remain fully supported until May 2030. New virtual machines can be deployed with Ubuntu Pro from the Azure Marketplace. You can also upgrade existing virtual machines to Ubuntu Pro by in-place upgrades via Azure CLI. More Information More information covering Ubuntu 20.04 LTS End of Standard Support can be found here. Refer to the documentation to learn more about handling Ubuntu 20.04 LTS on Azure. You can also check out Canonical’s blog post and watch the webinar here.
