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.
Red Hat Enterprise Linux Software Reservations Now Available
What's New After careful collaboration with Red Hat, we've updated our RHEL pay-as-you-go billing meters and reservation pricing to align with Red Hat's latest pricing model. These updates address previous billing meter issues and ensure an accurate, transparent experience for our customers. Starting today, customers can purchase RHEL software reservations on Azure with updated pricing, allowing organizations to reduce their Linux workload costs with the flexibility and reliability of software reservations. Key Benefits of RHEL Software Reservations Cost savings: Save up to 24% compared to pay-as-you-go pricing by committing to a one-year term Predictable costs: Lock in pricing for your RHEL workloads and optimize your cloud budget Pricing clarity: Updated meters aligned with Red Hat's current pricing model Seamless Azure integration: Manage your RHEL software reservations alongside other Azure resources. RHEL software reservations allow you to pre-purchase RHEL software capacity at a discounted rate, delivering significant savings over standard pay-as-you-go pricing. Get Started Today RHEL software reservations are available now on the Azure portal. To learn more about pricing, terms, and how to purchase them, visit the following pages: Pricing - Linux Virtual Machines | Microsoft Azure Prepay for software plans - Azure Reservations - Azure Virtual Machines | Microsoft Learn Red Hat reservation plan discounts - Azure - Microsoft Cost Management | Microsoft Learn What are Azure Reservations? - Microsoft Cost Management | Microsoft Learn We're committed to providing transparent, reliable billing for all Azure services and appreciate your continued partnership as we deliver the best cloud platform for your open-source workloads. For questions or support, please contact Azure Support or your Microsoft account team.Red Hat Enterprise Linux Billing Meter ID Updates on Azure
Background Following Red Hat's transition to a scalable vCPU-based pricing model in early 2024, Microsoft Azure implemented corresponding pricing updates for RHEL services. As part of ensuring our billing infrastructure fully supports this new pricing structure, we are updating the billing meter IDs for Red Hat Enterprise Linux services to provide better alignment with the current pricing model. What's Changing As part of optimizing our billing infrastructure to fully support Red Hat's updated pricing model, Microsoft Azure is updating the billing meter IDs for Red Hat Enterprise Linux (RHEL) services. These changes ensure our billing system properly accommodates the vCPU-based pricing structure and Reserved Instance functionality. Effective Date: The meter ID migration will begin rolling out on October 2-8, 2025. Impact on Customers Pay-As-You-Go (PAYG) Customers Billing Continuity: Your RHEL instances will continue to operate without any service interruption Meter ID Changes: New meter IDs will appear in your usage reports and cost management statements starting Oct 2-8, 2025 Usage Tracking: Historical usage data remains accessible through existing billing reports Important: No Pricing Impact This meter ID migration has no impact on pricing. Azure already implemented the RHEL pricing changes in early 2024. This meter ID update is purely a technical billing system change and does not affect your costs in any way. For pricing information, see the Pricing - Red Hat Virtual Machines | Microsoft Azure page. Action Required: Update Your Billing Tools To ensure uninterrupted monitoring and reporting, we recommend reviewing and updating the following: Billing Reports and Dashboards Cost Management Reports: Update any custom reports that filter by specific RHEL meter IDs Power BI Dashboards: Refresh data connections and update meter ID filters Third-party Tools: Verify that cost management tools recognize the new meter IDs Budget Alerts and Monitoring Budget Configurations: Review budgets that target specific RHEL services and update meter ID filters Cost Alerts: Ensure automated cost alerts include both old and new meter IDs during the transition period Spending Thresholds: Update any spending controls that rely on meter ID identification Automated Tools and Scripts Cost Analysis APIs: Update API calls that reference specific RHEL meter IDs Automation Scripts: Modify any scripts that process billing data using meter ID filters Integration Tools: Update third-party integrations that rely on meter ID mapping Transition Period Support During the migration period, you may see both old and new meter IDs in your statements. This is expected behavior as the transition occurs gradually across different regions and services. Timeline: October 2-8, 2025: New meter IDs begin appearing for RHEL Pay as you go meters Transition Period: Both old and new meter IDs may appear in billing during migration Completion: Migration will be completed across all regions and services Affected RHEL Meters The following RHEL meter names will be updated with new meter IDs as part of this migration: 1 vCPU VM License 1 vCPU VM License - Free 2 vCPU VM License 4 vCPU VM License 6 vCPU VM License 8 vCPU VM License 12 vCPU VM License 16 vCPU VM License 20 vCPU VM License 24 vCPU VM License 32 vCPU VM License 40 vCPU VM License 44 vCPU VM License 48 vCPU VM License 52-vCPU VM License 60 vCPU VM License 64 vCPU VM License 72 vCPU VM License 80 vCPU VM License 96 vCPU VM License 120 vCPU VM License 128 vCPU VM License 144-vCPU VM License 192 vCPU VM License 192-vCPU VM License 208 vCPU VM License 416 vCPU VM License 420-vCPU VM License These meter changes are tied to the vCPU count, not the VM family - meaning any VM with the same vCPU count (whether D family, E family, etc.) uses the same RHEL license meter. For example, all 2 vCPU VMs use the "2 vCPU VM License" meter regardless of the VM family. If your billing reports, budgets, or automated tools currently filter or reference any of these specific meter names, you'll need to update them to include the new meter IDs once the migration begins. Support and Resources Need Help? Azure Support: Contact Azure Support for technical assistance with billing or meter ID questions Account Team: Reach out to your Microsoft account team for guidance on updating enterprise billing processes Additional Resources: RHEL pricing update details: Red Hat Enterprise Linux Pricing update Azure cost optimization resources can be found here Frequently Asked Questions Q: Will this affect my RHEL instances or their performance? A: No, this is purely a billing system update. Your RHEL instances will continue to operate normally with no performance impact. Q: How can I identify the new meter IDs in my billing? A: New meter IDs will appear in your Cost Management portal and usage reports and cost management statements starting October 2-8, 2025. Watch for updated RHEL service descriptions in your billing details. Q: What if my automated tools stop working? A: Contact Azure Support for assistance. We recommend updating your tools proactively using the meter ID mapping reference provided. We're committed to making this transition as smooth as possible. If you have questions or need assistance, please reach out to Azure Support or your Microsoft account team.Red Hat Enterprise Linux 10 Image Mode on Azure Quick Start Guide
This guide will get you up and running with Image Mode on RHEL on Azure to help demonstrate how the technology works and how it can save you time and effort in managing your RHEL estate on Azure. To get started, you’ll need the following: Container Registry Linux server for building containers Azure Subscription for deploying a RHEL VM in Image Mode On an existing Linux system with “az” installed (and logged into an Azure account), let’s go ahead and begin by creating a resource group: az group create -l eastus -n linux-vms Now on that same system, let’s generate a ssh key for logging into vms: ssh-keygen -f ~/.ssh/linuxkey -t rsa And hit enter at both passphrase prompts. This will generate an ssh key for the purpose of this quickstart. In production, you may wish to actually use a passphrase to better protect your ssh keys. Now, we need to create a container registry. To do this on Azure, let’s go to https://portal.azure.com/#create/Microsoft.ContainerRegistry and on the first screen, specify an active subscription and choose “linux-vms” as our resource group. For the name of the registry, it must be unique across the Azure namespace, so try something with your name. In my case, my name is Karl and so I’m going to use “rhel10demo” for the purpose of this quick start. Anywhere you see that name, please replace it with your own registry name. Your first page should look similar to this when completed: Once you’ve filled those values in, click “Review + Create” and then on the next screen, click “Create”. Once the deployment finishes, you will have a container registry ready to go. Back over on our Linux system, let’s now deploy to Azure a Linux server for building containers: az vm create \ --resource-group linux-vms \ --name container-builder \ --image RedHat:rhel-raw:9_5:9.5.2024120516 \ --admin-username core \ --assign-identity \ --ssh-key-values ~/.ssh/linuxkey.pub\ --public-ip-sku Standard Once this command has completed, you’ll have a public ip address specified as the value for “publicAddress” in the output from the above command. This document will use ip.ip.ip.ip in place of an actual ip address to show you where you’d place the value. We also need to copy over our linuxkey.pub file to the container building machine so that we can inject this key into the container images we build: scp -i ~/.ssh/linuxkey ~/.ssh/linuxkey.pub core@ip.ip.ip.ip:.ssh/ Now let’s get started building our image mode container image! ssh core@ip.ip.ip.ip -i ~/.ssh/linuxkey First, we want to install podman and git: sudo dnf install -y podman git Now we need to have the Azure CLI tooling so that we can interact with our Azure Container Registry, to do that, let’s run: sudo rpm --import https://packages.microsoft.com/keys/microsoft.asc We now need to edit /etc/yum.repos.d/azure-cli.repo and make sure that it has the following contents: [azure-cli] name=Azure CLI baseurl=https://packages.microsoft.com/yumrepos/azure-cli enabled=1 gpgcheck=1 gpgkey=https://packages.microsoft.com/keys/microsoft.asc We can now run: sudo dnf install azure-cli -y Once this package has installed, we need to run: az login And follow the instructions. Let’s now generate a token credential granting us registry access by doing the following: (Remember to replace “rhel10demo” with your own registry name.) az acr token create --name mytoken --resource-group linux-vms --registry rhel10demo --scope-map _repositories_push "creationDate": "2025-04-23T14:02:59.654151+00:00", "credentials": { "certificates": null, "passwords": [ { "creationTime": "2025-04-23T14:03:10.774839+00:00", "expiry": null, "name": "password1", "value": "roF8leBAMlfeTS2Jb75WmaK/Z0WATcRK/sNowu6Str+ACRAZruef" }, { "creationTime": "2025-04-23T14:03:10.774858+00:00", "expiry": null, "name": "password2", "value": "vzRJsZwsp4PX/ToXTmAFQitz2yYye+dqHZXbbUXZrD+ACRBPzPXi" } ], "username": "mytoken" }, … In the output, we will see two passwords. Let’s grab password1, which in our example looks like: (You’ll want to save this information as it’s the only time you’ll get to see it!) "passwords": [ { "creationTime": "2025-04-23T14:03:10.774839+00:00", "expiry": null, "name": "password1", "value": "roF8leBAMlfeTS2Jb75WmaK/Z0WATcRK/sNowu6Str+ACRAZruef" }, Here the password is the value of the “value” parameter, and we can now log into the registry with the following command: (Remember to replace “rhel10demo” with your registry name.) podman login rhel10demo.azurecr.io -u mytoken -p roF8leBAMlfeTS2Jb75WmaK/Z0WATcRK/sNowu6Str+ACRAZruef Next, we want to clone the git repository that has our MSSQL Image Mode example: git clone https://github.com/mrguitar/rhel-mssql-bootc As we are using Azure PAYG (Pay as you Go) images, we need to enable RHUI access inside of containers by running: sudo sh -c "echo -e '/usr/share/rhel/secrets:/run/secrets\n/etc/pki/rhui:/etc/pki/rhui\n/etc/yum.repos.d/rh-cloud-base.repo:/etc/yum.repos.d/rh-cloud-base.repo' >> /etc/containers/mounts.conf" sudo chmod 644 /etc/pki/rhui/{private,product}/* Now, let’s change into the directory of our git repository and copy our auth.json for our container: cd rhel-mssql-bootc mkdir -p etc/ostree cp /run/user/1000/containers/auth.json ./etc/ostree/ We can now examine the Containerfile.azure and see that it has instructions to build and bring up a system. In the from container, we already have MIcrosoft SQL Server installed, so we do not have to add that to our container: FROM quay.io/mrguitar/rhel-mssql-bootc:latest COPY etc/ /etc/ COPY 05-cloud-kargs.toml /usr/lib/bootc/kargs.d/ ARG sshpubkey RUN if test -z "$sshpubkey"; then echo "must provide sshpubkey"; exit 1; fi; \ useradd -G wheel core && \ mkdir -m 0700 -p /home/core/.ssh && \ echo $sshpubkey > /home/core/.ssh/authorized_keys && \ chmod 0600 /home/core/.ssh/authorized_keys && \ chown -R core: /home/core # install required packages and enable services RUN dnf -y install \ WALinuxAgent \ cloud-init \ cloud-utils-growpart \ gdisk \ hyperv-daemons && \ dnf clean all && \ systemctl enable NetworkManager.service && \ systemctl enable waagent.service && \ systemctl enable cloud-init.service && \ echo 'ClientAliveInterval 180' >> /etc/ssh/sshd_config # configure waagent for cloud-init to handle provisioning RUN sed -i 's/Provisioning.Agent=auto/Provisioning.Agent=cloud-init/g' /etc/waagent.conf && \ sed -i 's/ResourceDisk.Format=y/ResourceDisk.Format=n/g' /etc/waagent.conf && \ sed -i 's/ResourceDisk.EnableSwap=y/ResourceDisk.EnableSwap=n/g' /etc/waagent.conf We can now build the container image by running: podman build --build-arg "sshpubkey=$(cat ~/.ssh/linuxkey.pub)" --no-cache -f Containerfile.azure Now that we have our container registry configured and our image built, we can push the image to the registry. Let’s start by finding the image ID for our newly built image: [core@container-builder rhel-mssql-bootc]$ podman images REPOSITORY TAG IMAGE ID CREATED SIZE <none> <none> ba4f948305db 2 minutes ago 3.64 GB quay.io/mrguitar/rhel-mssql-bootc latest 534ac925516a 4 weeks ago 3.47 GB We can now tag this image with the following command (Remember to replace “rhel10demo” with your registry name.): podman tag ba4f948305db rhel10demo.azurecr.io/mssql-image-mode:azure Now we can push our image to our registry: podman push rhel10demo.azurecr.io/mssql-image-mode:azure Now, let’s exit from the container building server and go create a new RHEL 9.5 VM that we will switch from package mode to image mode. This needs to be run on the system that you created the container building image on. az vm create \ --resource-group linux-vms \ --name mssql \ --image RedHat:rhel-raw:9_5:9.5.2024120516 \ --admin-username core \ --assign-identity \ --ssh-key-values ~/.ssh/linuxkey.pub \ --public-ip-sku Standard Once this machine starts, let’s ssh to the system: ssh -i ~/.ssh/linuxkey core@ip.ip.ip.ip Let’s start by installing podman: sudo dnf install podman -y Now we must login to our container registry using sudo so that podman running as root can download our container image: (We will use the credentials that were generated earlier in this quick start.) sudo podman login rhel10demo.azurecr.io -u mytoken -p roF8leBAMlfeTS2Jb75WmaK/Z0WATcRK/sNowu6Str+ACRAZruef and then we can run the following command to pull down our image mode image and deploy it to this system: sudo podman run --privileged --pid=host -v /var/lib/containers:/var/lib/containers -v /:/target -v /home/core/.ssh/authorized_keys:/bootc_authorized_ssh_keys/root rhel10demo.azurecr.io/mssql-image-mode:azure bootc install to-existing-root --acknowledge-destructive --root-ssh-authorized-keys /bootc_authorized_ssh_keys/root At this point, when the above command completes successfully, you can run: sudo systemctl reboot And when you reboot, your RHEL system will now be running in Image Mode! Let’s go ahead and log back in and see what’s different: ssh -i ~/.ssh/linuxkey core@ip.ip.ip.ip Let’s start by trying to create a file in /opt as root – something you could normally do on package mode RHEL: sudo touch /opt/hello.txt If you are on an image mode system, you’ll see this output: touch: cannot touch 'hello.txt': Read-only file system This is because the files in the container image are immutable and the only way to change them is to change the image and reboot into the image! This provides a significant new layer of security in that operating system files cannot be easily modified. You are still able to edit files in /etc and in home directories. This image has Microsoft SQL Server installed and we can verify this by running: sudo systemctl status mssql-server You should see output similar to: ○ mssql-server.service - Microsoft SQL Server Database Engine Loaded: loaded (/usr/lib/systemd/system/mssql-server.service; disabled; preset: disabled) Active: inactive (dead) Docs: https://docs.microsoft.com/en-us/sql/linux Given that we want all virtual machines based on this image to have SQL Server running by default, let’s make that change to the container image. To do this, we’ll need to exit this shell and ssh into the container builder machine from earlier. On that machine, run: cd rhel-mssql-bootc And then use this command to add “RUN systemctl enable mssql-server.service” to the end of Containerfile.azure: echo >> Containerfile.azure && echo "RUN systemctl enable mssql-server.service" >> Containerfile.azure Once this is done, we need to rebuild the image, tag the rebuilt image, and push the new image to our container registry: (Remember to replace “rhel10demo” with your registry name.) podman build --build-arg "sshpubkey=$(cat ~/.ssh/linuxkey.pub)" --no-cache -f Containerfile.azure podman images REPOSITORY TAG IMAGE ID CREATED SIZE <none> <none> b7322184d64e 9 seconds ago 3.67 GB rhel10demo.azurecr.io/mssql-image-mode azure 237947455bd9 53 minutes ago 3.67 GB quay.io/mrguitar/rhel-mssql-bootc latest e36c92d89714 4 days ago 3.5 GB podman tag b7322184d64e rhel10demo.azurecr.io/mssql-image-mode:azure cp etc/ostree/auth.json /run/user/1000/containers podman push rhel10demo.azurecr.io/mssql-image-mode:azure Once this is done, we can exit this machine and log back on to our image mode machine and run the following: sudo bootc upgrade sudo systemctl reboot And watch the magic as the box reboots! Now when you ssh in again, run: sudo systemctl status mssql-server This time, you should get output showing that SQL Server is running. Upon updating and rebooting all VMs based on this image, they’ll now be running SQL Server. At this point, we can run the SQL Server demo by running: sudo PATH=$PATH:/opt/mssql/bin/ /opt/mssql_demo.sh This demo shows that the SQL Server is working on our RHEL machine running in Image Mode. Any further changes that you want to make to this box can be pushed by changing the container image in the registry and calling a bootc upgrade. Image Mode RHEL also ships with a timer that allows these boxes to check for updates on the weekend. This can be configured so that not all of your image mode RHEL boxes update at the same time. With Image Mode RHEL, you don’t have to worry about system drift as you are always running off of a known image. Also, you’ll probably find yourself saving a lot of time by not having to log on to lots of systems. If you need to spin up 1,000 VMs with the same image, you can easily do that with the tooling we’ve shown you today on top of Azure!Azure 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 GroupLinux and Open Source on Azure Quarterly Update - February 2025
As we venture into 2025, it's exhilarating to reflect on the astonishing strides we've made in the domain of Linux and Open Source Software (OSS) on Azure. Let us dive into another edition of the quarterly update to learn more! Microsoft Ignite 2024 Linux on Azure took center stage at Microsoft Ignite 2024 with dedicated session and a meet-up booth. Our breakout session, theater session, and lab session drew over 500 attendees. This engagement is a testament to the enthusiasm and interest in Linux-based solutions on Azure. Check out the on-demand recording available on the Ignite website: What’s new in Linux: How we’re collaborating to help shape its future We announced that the Azure security baseline through Azure Policy and Machine Configuration for Linux has moved to public preview, and we are expanding the capabilities with built-in auto-remediation feature (limited public preview). Red Hat on Azure announcements at Ignite are captured here. Linux Promotional Offer The promotional offer for the latest Linux VMs in Azure is currently live. For a limited time, you can save an additional 15% on one-year Azure Reserved Virtual Machine (VM) Instances for the latest Linux VMs. This means you could save up to 56% compared to running an Azure VM on a PAYG (pay-as-you-go) basis. This offer is available until March 31, 2025. To learn more, read the blog and refer to the terms and conditions. Azure Linux 3.0 in preview on Azure Kubernetes Service v1.31 We are excited to announce that Azure Linux 3.0, the next major version release of the Azure Linux container host for Azure Kubernetes Service (AKS), is now available in preview on AKS version 1.31. Azure Linux 3.0 offers increased package availability and versions, an updated kernel, and improvements to performance, security, and tooling and developer experience. SUSE LTSS on Azure Marketplace Many of our customers rely on SUSE Linux Enterprise Server (SLES) for running their mission-critical SAP and HPC (high-performance computing) workloads on Azure. We’re excited to share that SUSE Long Term Service Pack Support (LTSS) is available in the Azure Marketplace, providing customers with options for managing the support lifecycle of their SUSE images in Azure. The blog announcement is here. Linux VM Image Quality on Azure In the continuously evolving landscape of cloud computing and AI, the quality and reliability of virtual machines (VMs) plays a vital role for businesses running mission-critical workloads. With over 65% of Azure workloads running Linux, our commitment to delivering high-quality Linux VM images and platforms remains unwavering. Find out how Microsoft ensures the quality of Linux VM images and platform experiences on Azure. Learn how LISA (an open-source tool) enhances the testing and validation processes for Linux kernels and guest OS images on Azure. MIT Technology Review Article We recently commissioned a sponsored article in collaboration with AMD on the topic of “Accelerating AI innovation through application modernization” published on MIT Technology Review. The article delves into AI driving new requirements for application modernization. Red Hat Summit Connects Microsoft’s sponsorship of the Red Hat Summit Connect global event series proved to be a resounding success. Spanning cities from Melbourne to Mexico City, we engaged with over 6,500 attendees. By partnering with key organizations, we reinforced the strength of our strategic alliance with Red Hat. What’s coming up next Migrate to Innovate Summit This event aims to showcase how cloud migration and modernization can build a platform for AI innovation. In 2.5 hours, the event will feature thought leaders and experts from Microsoft and Intel who will share their perspectives, present real-world case studies, and showcase product demonstrations to help customers accelerate their cloud journey. The event will be live on March 11, 2025. Register to check out the great content! SUSECON 2025 We will be at SUSECON 2025, which will take place in Orlando, Florida, from March 10th – 14th, 2025. We look forward to sharing insights, learning, and collaborating with everyone attending. Discover why Microsoft Azure is a trusted and proven cloud platform and explore the benefits of Azure-optimized solutions co-developed by Microsoft and SUSE for your business-critical Linux workloads. Check out one of the Microsoft sessions and meet with us at our booth. We recently published a recap covering some of Microsoft partners’ latest offerings on Linux and PGSQL. Stay tuned for more updates and thank you for being a part of this journey!From Compliance to Auto-Remediation: Azure's Latest Linux Security Innovations
We are pleased to announce that the Azure security baseline through Azure Policy and Machine Configuration for Linux has moved to public preview, and we are expanding the capabilities with built-in auto-remediation feature (limited public preview). Customers face increasing pressure to comply with requirements set by governments, regulatory bodies, or specific industries. As their environments become more complex and hybrid, achieving and maintaining compliance on a large scale remains challenging and problematic. Failing to meet compliance goals can result in substantial business harm, including financial penalties and the potential loss of customers. Introducing enhanced audit and the new auto-remediation experience: Recognizing the above-mentioned challenges, Microsoft has developed a solution to help customers navigate these complexities at ease. The Azure security baseline for Linux offers compliance and built-in auto-remediation (limited public preview) features via Azure Policy’s Machine Configuration and Microsoft’s open-source Azure-OSconfig engine. The combination of these capabilities will ensure that security is embedded by design and compliance requirements are upheld, whether workloads operate in the cloud, on-premises, or in another CSP environment, through the Azure Arc platform. Thanks to the new approach we provide detailed information about the state of compliance and more accurate results with detailed descriptions with direct reference to the CIS rule definitions. Furthermore, the new architecture has enabled us to implement and provide automatic remediation capabilities against the security baseline providing a Linux-native experience for our customers when it comes to hardening. Microsoft has implemented a streamlined version of Linux security best practices, primarily based on the latest CIS (Center for Internet Security) Distribution Independent Linux benchmark. All the audit and remediation results are available and can be queried within the Azure Resource Graph Explorer for reporting and monitoring purposes. As security is Microsoft’s top priority, we will provide these capabilities at no additional cost to our customers, with charges only applying to the Azure Arc managed workloads hosted on-premises or other CSP environments. What’s next: At Microsoft we strive to continuously improve customer satisfaction - understanding that a one-size-fits-all approach is not feasible for hardening and security, we are committed to working with our customers throughout the preview process to improve the end-to-end experience. In addition to that, Microsoft is committed to evolve and further develop and deliver new security baseline contents to be fully aligned with the latest CIS standards across various Linux distributions and will collaborate with the relevant standard bodies to contribute to the standards, benefiting both the broader community and the wider industry. Stay tuned in this space for more information - exciting news to come in the upcoming months! What happens with the existing Azure security baseline for Linux capability: Every VM customer which has the “Linux machines should meet requirements for the Azure compute security baseline” policy definition assigned will be auto migrated by the Azure team in the upcoming months to the new policy definition. (audit only) We are going to do a gradual rollout of this enhanced capability. For the time being approximately 3-6 months post announcement, the existing policy will still be available and then it will be deprecated and removed from the Azure portal. Learn more: Sign-up form for the auto-remediation capability Read more about Azure Arc Check out the Azure osconfig’s GitHub repo Comparison between old and new baseline is attached to the blog List of supported operating systems (check the Linux distros in the table)Red Hat at Microsoft Ignite: Pioneering Innovation for the Cloud
Microsoft Ignite 2024 brought with it groundbreaking announcements, and Red Hat stood at the forefront, unveiling a series of innovations designed to empower businesses across industries. These announcements further strengthened the partnership between Red Hat and Microsoft, showcasing their joint commitment to delivering open-source solutions tailored for modern cloud workloads. In this blog, we’ll explore the key announcements made by Red Hat at Microsoft Ignite and how they align with the evolving needs of enterprises, from AI-driven workloads to high-performance computing, hybrid environments, and beyond. 1. Landing Zone for RHEL on Azure: Simplifying Migration One of the most exciting developments is the Landing Zone for Red Hat Enterprise Linux (RHEL) on Azure. This initiative provides organizations with a streamlined path to migrate their RHEL workloads to Azure. By leveraging the Landing Zone, businesses can: Simplify cloud adoption through pre-configured environments. Ensure compliance and best practices with built-in governance and security measures. Enhance operational efficiency by integrating with Azure-native tools. This offering caters to organizations at various stages of cloud adoption, empowering them to accelerate their journey to Azure with minimal friction. Learn more about this transformative capability here. 2. Red Hat JBoss EAP 8 on Azure: The Future of Java Workloads Red Hat also introduced Red Hat JBoss Enterprise Application Platform (EAP) 8 on Azure. This fully supported, jointly produced solution is a game-changer for Java developers aiming to modernize their applications in the cloud. Key benefits of this integration include: Seamless deployment of Java workloads in Azure environments. Enhanced support for microservices architecture. Access to Azure’s global scale, enabling developers to innovate faster and meet growing application demands. For developers and businesses relying on Java for critical workloads, this announcement solidifies Azure as a destination for innovation and modernization. Explore the details here. 3. HPC on Azure: Scaling Compute with RHEL The demand for high-performance computing (HPC) in industries like finance, healthcare, and engineering has never been greater. Addressing this, Red Hat has made significant strides in enabling RHEL for HPC on Azure. This development allows businesses to: Scale their compute capabilities dynamically. Leverage Azure’s robust infrastructure for intensive computational workloads. Integrate with RHEL’s ecosystem for consistent and secure performance. With this solution, Red Hat empowers organizations to meet the demands of data-heavy applications, ensuring they stay ahead in competitive markets. Dive deeper into RHEL for HPC on Azure here. 4. RHEL Meets Windows Subsystem for Linux (WSL): A New Era of Hybrid Environments In a landmark announcement, Red Hat Enterprise Linux is now available on Windows Subsystem for Linux (WSL). This collaboration bridges the gap between Linux and Windows environments, offering unprecedented flexibility to developers and IT professionals. Key highlights include: Access to RHEL’s trusted ecosystem on Windows devices. Streamlined development workflows for hybrid IT environments. Enhanced compatibility for organizations operating in multi-platform setups. This integration marks a significant step forward in breaking down barriers between operating systems, enabling developers to work seamlessly across their preferred environments. Learn more about this innovative solution here. 5. RHEL for SAP: Unlocking Value in Public Cloud Marketplaces SAP workloads demand stability, scalability, and high availability. Recognizing this, Red Hat announced RHEL for SAP in public cloud marketplaces, including Azure. With this offering, SAP customers can: Simplify procurement and deployment through Azure Marketplace. Leverage RHEL’s certified configurations for optimized performance. Reduce operational complexity with integrated support from Red Hat and Microsoft. This solution addresses the unique challenges of SAP workloads, empowering businesses to maximize their investment in SAP applications. More details can be found here. 6. RHEL AI: Empowering Generative AI Workloads As AI transforms industries, Red Hat unveiled RHEL AI, a solution designed to cater to generative AI workloads on Azure. This new offering provides enterprises with the flexibility and tools needed to harness the power of AI at scale. Key features include: Pre-configured RHEL environments optimized for AI/ML workloads. Integration with Azure AI services for accelerated deployment. A secure, scalable foundation for training and deploying AI models. This announcement underscores Red Hat’s commitment to staying at the forefront of innovation, empowering businesses to explore new frontiers in AI. Learn more about RHEL AI here. 7. Azure Red Hat OpenShift: Advancing Cloud Security with Confidential Containers Red Hat and Microsoft unveiled a significant advancement in cloud security with the public preview of Confidential Containers on Azure Red Hat OpenShift (ARO). This innovative solution brought hardware-based security measures to containerized workloads, offering unprecedented protection for sensitive data and applications. Key features included: Advanced memory encryption and secure workload execution using AMD SEV-SNP technology and Intel TDX capable instances Enhanced protection that safeguarded workloads even from cloud operator access Seamless integration with existing container deployment workflows and tools Zero additional costs during the preview period beyond standard Azure compute and ARO charges This solution was particularly valuable for organizations in healthcare, financial services, and regulated industries where data security is paramount. It also provided robust protection for sensitive AI/ML workloads. Organizations interested in enhancing their cloud security posture could explore this new capability through the preview program. To learn more, click here for more information. 8. Azure Red Hat OpenShift: Streamlining Enterprise AI Development Red Hat and Microsoft announced a significant advancement in their AI capabilities through Azure Red Hat OpenShift (ARO), addressing the challenges of deploying business-ready AI applications. This collaboration focused on integrating DevOps pipelines with data science workflows, enabling teams to prioritize AI model optimization over infrastructure management. Key features included: Pre-integrated DevOps and data science pipelines that streamlined deployment processes and accelerated time to value Enhanced AI performance capabilities through Red Hat OpenShift AI, Azure OpenAI, and RAG (retrieval-augmented generation) techniques GitOps deployment functionality utilizing ArgoCD templates for efficient production rollouts of AI models The integration demonstrated how organizations could leverage familiar tools and processes to accelerate their AI journey. To learn more, click here for more information. 9. Managed Identities Enhance Security in Azure Red Hat OpenShift Microsoft and Red Hat announced a significant security advancement for Azure Red Hat OpenShift (ARO) with the introduction of managed identity and workload identity support. This update marked a shift away from traditional long-lived credentials toward more secure, short-term privileged access mechanisms. Key features included: Implementation of eight distinct managed identities with built-in roles for different OpenShift components Short-lived credentials that eliminated the need for manual credential management Refined permission sets following the principle of least privilege Support for customer workload identities through Service Account Token Volume Projection and OIDC federation This enhancement addressed previous limitations where ARO required service principals with broad contributor-level access. The new approach provided granular control over permissions while improving security through time-bound access tokens. The announcement revealed plans for a preview release in early 2025, with multiple deployment options including an "all-in-one" command for streamlined implementation. To learn more, click here for more information. The announcements at Microsoft Ignite 2024 highlight the deepening collaboration between Red Hat and Microsoft. Together, they are shaping the future of enterprise IT by delivering innovative solutions that cater to the unique demands of modern workloads. To explore these innovations and how they can transform your IT landscape, visit Red Hat’s Ignite Page Stay tuned for more updates and insights as we continue to innovate together!
