https://ubuntu.com//blog/feedUbuntu blog feedhttp://www.rssboard.org/rss-specificationPython FeedgenThu, 18 Jun 2026 12:35:08 +0000https://ubuntu.com//blog/validating-real-world-skills-through-canonical-academy<p>In an increasingly volatile job market, standing out from the competition is vital. For many in the open source community, formal recognition for self-taught skills is a significant challenge. These skills are often built through hands-on hobbies, side projects, and deep community contributions. While the market is flooded with certificates and certifications, most fail to [&hellip;]</p> <p>In an increasingly volatile job market, standing out from the competition is vital. For many in the open source community, formal recognition for self-taught skills is a significant challenge. These skills are often built through hands-on hobbies, side projects, and deep community contributions. While the market is flooded with certificates and certifications, most fail to reliably measure practical execution, or fall behind the rapid pace of industry changes. Others demand a time commitment that busy professionals simply cannot afford.</p> <p>Self-paced or instructor-led courses offer certificates of participation that acknowledge time spent rather than competence demonstrated. Meanwhile, traditional professional certifications often rely on dense, theoretical, multiple-choice formats. These are expensive, time-consuming, and they leave both the candidate and the employer unsure if real-world capability was actually proven. Even respected hands-on exams can suffer from diminishing industry relevance if their subject matter fails to update alongside modern, remote-first workflows.</p> <h2 class="wp-block-heading">A new standard for professional qualifications</h2> <p>As the company behind Ubuntu, Canonical has always focused on making complex systems accessible to everyone. When we looked at the engineering certification landscape, we saw an opportunity to design a highly credible, data-driven framework. This framework is built specifically for the needs of modern enterprises and professionals. The result is Canonical Academy.</p> <p>We moved away from isolated tests to introduce structured, job-based <strong>Qualifications</strong>. Each qualification maps directly to a professional role. It is achieved by passing a series of modular, real-world exams. This design ensures deep coverage of both foundational industry standards and specific, modern operational methodologies.</p> <p>To ensure our curriculum reflects absolute professional relevance, our process begins with an extensive Job Task Analysis (JTA). This analysis surveys industry experts to map exactly what employers expect from technical professionals. We established our initial focus on the System Administrator (SysAdmin) track. These fundamental operational skills form the bedrock for roles spanning from DevOps engineers to data scientists.</p> <h2 class="wp-block-heading">Built with rigor, monitored for quality</h2> <p>To turn these functional performance expectations into reality, we assemble diverse panels of subject matter experts (SMEs). These experts come from Canonical support, operations, core engineering, and the open source community. Together, we build realistic, multi-node lab environments and write intelligent grading scripts. Rather than forcing a single rigid solution, our grading architecture evaluates the end state of a system. This enables test-takers to showcase their personal problem-solving style and task execution efficiency.</p> <p>What truly differentiates Canonical Academy is our commitment to continuous structural quality:</p> <ul> <li><strong>LTS alignment:</strong> Exams are continuously updated and versioned alongside every Ubuntu Long Term Supported (LTS) release. This ensures your credentials remain strictly aligned with enterprise production environments.</li> <li><strong>Psychometric rigor:</strong> Every single exam item is monitored using advanced instructional design metrics. This maintains consistent difficulty and eliminates measurement bias across different question variations.</li> <li><strong>Accessible and secure delivery:</strong> Delivered entirely through a standard web browser, our platform combines hands-on terminal realism with secure remote proctoring. No need to clear half a day to travel to a physical testing center.</li> </ul> <h2 class="wp-block-heading">The path forward: modular learning and continuous growth</h2> <p>By breaking our qualifications down into modular exams, professionals can validate their skills at their own pace and budget.</p> <p>Our rollout roadmap is designed to systematically validate skills across the full spectrum of systems administration:</p> <figure class="wp-block-table"><table><tbody><tr><td><strong>Exam Track</strong></td><td><strong>Focus Areas</strong></td><td><strong>Status</strong></td></tr><tr><td><strong>Using Linux Terminal</strong></td><td>Navigating filesystems, file management, basic security, and command-line mechanics.</td><td><strong>Available now</strong></td></tr><tr><td><strong>Using Ubuntu Desktop</strong></td><td>Package management, application essentials, and desktop administration.</td><td><strong>Available now</strong></td></tr><tr><td><strong>Using Ubuntu Server</strong></td><td>Job control, services setup and management, server security, and basic server deployment</td><td><strong>General Availability coming soon</strong></td></tr><tr><td><strong>Using DevOps Principles</strong></td><td>System automation and deployment, management of updates and patches, application and system monitoring, and troubleshooting connected systems.</td><td><strong>Beta coming soon</strong></td></tr></tbody></table></figure> <p>Ultimately, a qualification from Canonical Academy is more than just a badge to display on a resume. It is verifiable proof of competency engineered by the publishers of Ubuntu. Whether you are an individual aiming to prove self-taught expertise, an educator expanding student employability, or an enterprise leader looking to benchmark your engineering team’s capabilities, Canonical Academy provides the pathway to validated open source skills.</p> <p>Join us on the journey, explore our tracks, and take your next exam at <a href="https://canonical.com/academy">canonical.com/academy</a>.</p> Ishani Ghoshal (Ishani Ghoshal)Canonical AcademyWed, 17 Jun 2026 13:12:52 +0000https://ubuntu.com//blog/virtualized-android-comes-to-anbox-cloud<p>With our latest 1.30.0 Anbox Cloud release, available today, we are introducing one of the most significant evolutions of the platform to date: support for virtualized Android.&nbsp; For the first time, Anbox Cloud can launch complete Android system images inside lightweight virtual machines, managed and orchestrated through the same Anbox APIs our users already rely [&hellip;]</p> <p>With our latest 1.30.0 Anbox Cloud release, available today, we are introducing one of the most significant evolutions of the platform to date: support for virtualized Android. </p> <p>For the first time, Anbox Cloud can launch complete Android system images inside lightweight virtual machines, managed and orchestrated through the same Anbox APIs our users already rely on.</p> <p>This new capability does not replace what Anbox Cloud already does well; it expands it. Containerized Android remains a first-class citizen, and virtualized Android adds a powerful new option when full system fidelity is required.</p> <h1 class="wp-block-heading">Two paths, one platform</h1> <figure class="wp-block-image size-full"><img alt="" height="900" loading="lazy" sizes="(min-width: 1800px) 1800px, 100vw" src="https://res.cloudinary.com/canonical/image/fetch/f_auto,q_auto,fl_sanitize,c_fill,w_1800/https%3A%2F%2Fubuntu.com%2Fwp-content%2Fuploads%2Fcfd6%2Fimage.png" srcset="https://res.cloudinary.com/canonical/image/fetch/f_auto,q_auto,fl_sanitize,c_fill,w_460/https%3A%2F%2Fubuntu.com%2Fwp-content%2Fuploads%2Fcfd6%2Fimage.png 460w, https://res.cloudinary.com/canonical/image/fetch/f_auto,q_auto,fl_sanitize,c_fill,w_620/https%3A%2F%2Fubuntu.com%2Fwp-content%2Fuploads%2Fcfd6%2Fimage.png 620w, https://res.cloudinary.com/canonical/image/fetch/f_auto,q_auto,fl_sanitize,c_fill,w_1036/https%3A%2F%2Fubuntu.com%2Fwp-content%2Fuploads%2Fcfd6%2Fimage.png 1036w, https://res.cloudinary.com/canonical/image/fetch/f_auto,q_auto,fl_sanitize,c_fill,w_1681/https%3A%2F%2Fubuntu.com%2Fwp-content%2Fuploads%2Fcfd6%2Fimage.png 1681w, https://res.cloudinary.com/canonical/image/fetch/f_auto,q_auto,fl_sanitize,c_fill,w_1920/https%3A%2F%2Fubuntu.com%2Fwp-content%2Fuploads%2Fcfd6%2Fimage.png 1920w, https://res.cloudinary.com/canonical/image/fetch/f_auto,q_auto,fl_sanitize,c_fill,w_1800/https%3A%2F%2Fubuntu.com%2Fwp-content%2Fuploads%2Fcfd6%2Fimage.png 1800w" width="1800"/></figure> <p>We initially designed Anbox Cloud with containerized Android in mind because we consider that containers are an excellent fit for most cloud workloads that require fast and easy scaling. Indeed, containers are quick to start, they require fewer resources, and they work seamlessly with most orchestration systems. Today, containerized Android is still the ideal approach for large-scale Android application deployments for multiple use cases such as streaming, testing, automation, etc.</p> <p>However, we’ve been seeing an increase in demand for workloads that go beyond applications and that would require full control over the Android system. Custom kernels, modified system services, vendor-specific components, or close alignment with physical devices all fall into this category. These are precisely the cases where containerization alone becomes restrictive and virtualized Android solutions, like Cuttlefish, become a better fit.</p> <p>Virtualized Android fills this gap by allowing Android to run as a full system within a virtual machine (VM), while still allowing users to benefit from Anbox Cloud’s existing features like instance management, automation, and scalability.</p> <blockquote class="wp-block-quote"> <p>“With virtualized Android in Anbox Cloud, developers can now run complete Android system images on cloud and bare-metal infrastructure such as Google Cloud C4A-metal.”  says Cedric Gegout, Canonical VP of Products. “This gives engineering teams a new way to industrialize Android: consistent environments, repeatable pipelines, higher density, and infrastructure that can be managed like any other cloud-native workload.”</p> </blockquote> <p>Teams using highly customized Android images can easily transition them to the cloud without sacrificing quality. </p> <p>Developers using Cuttlefish-based images can now enjoy a scalable environment that fits perfectly into their CI and automation workflows. Automotive OEMs, who usually deeply modify their Android Automotive OS (AAOS) images, can test entire Android systems in a consistent, cloud-native environment.</p> <p>All of this takes place within the same Anbox Cloud experience that our users enjoy: the APIs, tooling, and workflows remain consistent, regardless of how Android is executed.</p> <h1 class="wp-block-heading">What really changed under the hood</h1> <p>This release represents a significant architectural shift.</p> <p>Historically, Android in Anbox Cloud always ran as a containerized Android system. Typically, that container was hosted as an Android container running inside another container.<br/></p> <p>While this gave us flexibility at the infrastructure level, Android itself was still constrained to a container environment. With this new release, that changes.</p> <p>Anbox Cloud now supports two distinct Android execution models:</p> <ul> <li>An Android container running inside a container</li> <li>A full Android virtual machine running inside a container</li> </ul> <p class="has-text-align-center"></p> <figure class="wp-block-image size-full"><img alt="" height="1154" loading="lazy" sizes="(min-width: 1480px) 1480px, 100vw" src="https://res.cloudinary.com/canonical/image/fetch/f_auto,q_auto,fl_sanitize,c_fill,w_1480/https%3A%2F%2Fubuntu.com%2Fwp-content%2Fuploads%2Fbe9d%2Funnamed.png" srcset="https://res.cloudinary.com/canonical/image/fetch/f_auto,q_auto,fl_sanitize,c_fill,w_460/https%3A%2F%2Fubuntu.com%2Fwp-content%2Fuploads%2Fbe9d%2Funnamed.png 460w, https://res.cloudinary.com/canonical/image/fetch/f_auto,q_auto,fl_sanitize,c_fill,w_620/https%3A%2F%2Fubuntu.com%2Fwp-content%2Fuploads%2Fbe9d%2Funnamed.png 620w, https://res.cloudinary.com/canonical/image/fetch/f_auto,q_auto,fl_sanitize,c_fill,w_1036/https%3A%2F%2Fubuntu.com%2Fwp-content%2Fuploads%2Fbe9d%2Funnamed.png 1036w, https://res.cloudinary.com/canonical/image/fetch/f_auto,q_auto,fl_sanitize,c_fill,w_1681/https%3A%2F%2Fubuntu.com%2Fwp-content%2Fuploads%2Fbe9d%2Funnamed.png 1681w, https://res.cloudinary.com/canonical/image/fetch/f_auto,q_auto,fl_sanitize,c_fill,w_1920/https%3A%2F%2Fubuntu.com%2Fwp-content%2Fuploads%2Fbe9d%2Funnamed.png 1920w, https://res.cloudinary.com/canonical/image/fetch/f_auto,q_auto,fl_sanitize,c_fill,w_1480/https%3A%2F%2Fubuntu.com%2Fwp-content%2Fuploads%2Fbe9d%2Funnamed.png 1480w" width="1480"/></figure> <p class="has-text-align-center"><em>Representation of a key difference between virtualized Android and containerized Android </em></p> <p>In other words, Android is no longer always containerized. When using the virtualized option, Android runs as a complete VM, with its own kernel and system environment, enabling significantly broader compatibility with custom and modified system images.</p> <p>More importantly, <a href="https://canonical.com/lxd">LXD</a> remains the foundation of everything. Whether Android is running in a container or a virtual machine, Anbox Cloud still relies on LXD for strong isolation, simple resource management, and orchestration, preserving our users’ familiar operating model.</p> <h1 class="wp-block-heading">When is virtualized Android more suitable than containerized Android?</h1> <p>The addition of virtualized Android is about choosing the right tool for the job.</p> <p>When you require complete control over the Android system image, virtualized Android is the best choice. This includes custom Android Open Source Project (AOSP) or AAOS builds, OEM-specific images, and modified Google reference images such as Cuttlefish. </p> <p>It’s ideal for system validation, device-level testing, platform development, and any workload that relies on low-level Android behavior.</p> <p>When it comes to applications rather than the operating system, containerized Android is still the best option. Indeed, for Android apps, containers continue to provide superior scaling efficiency and simplicity for high-density deployments and fast startup times.</p> <p>Both approaches have clear advantages, and Anbox Cloud now supports both rather than forcing users to choose between them.</p> <h1 class="wp-block-heading">Looking ahead</h1> <p>This release is a major step toward our long-term vision: making Anbox Cloud the most powerful platform for running Android in the cloud, whether at the application level or at the full system level.</p> <p>Containerized Android continues to deliver speed and scale, whereas virtualized Android provides compatibility and control. With both options, Anbox Cloud gives our users the freedom to select what works best for their workloads now and in the future.</p> <p>If you are looking for architectural and technical details, download our latest whitepaper <a href="https://ubuntu.com/engage/virtualized-android">“From containerized Android™ to full system virtualization”.</a></p> <p>Try it now and stay tuned for further developments in our upcoming releases. For detailed instructions on how to upgrade your existing deployment, please refer to the <a href="https://documentation.ubuntu.com/anbox-cloud/en/latest/howto/update/upgrade-anbox/#howto-upgrade-anbox-cloud">Anbox Cloud documentation.</a></p> <h1 class="wp-block-heading"><strong>Further reading</strong></h1> <p>Learn everything about virtualized Android with Anbox Cloud <a href="https://ubuntu.com/engage/virtualized-android">in our latest whitepaper.</a><br/><a href="https://documentation.ubuntu.com/anbox-cloud/#">If you need details to get started, go through our Anbox Cloud documentation<br/></a><a href="https://canonical.com/anbox-cloud#get-in-touch">Learn more about Anbox Cloud or contact our team to discuss your use case</a></p> <hr class="wp-block-separator has-alpha-channel-opacity"/> <p>Android is a trademark of Google LLC. <br/>Anbox Cloud uses assets available through the Android Open Source Project.<br/>The Android robot is reproduced or modified from work created and shared by Google and used according to terms described in the<a href="https://creativecommons.org/licenses/by/3.0/"> Creative Commons</a> 3.0 Attribution License.</p> Bertrand Boisseau (Bertrand Boisseau)Anboxanbox cloudAnbox Cloud ApplianceWed, 17 Jun 2026 12:58:51 +0000https://ubuntu.com//blog/template-streamlining-open-source-design-contributions<p>As designers working at Canonical, we’re always thinking about open source. We believe that encouraging more designers to contribute to open source&nbsp; benefits everyone, from the project maintainers to the end users themselves.&nbsp;&nbsp; In the 2025 edition of FOSSBackstage conference, we presented our research findings on&nbsp; why designers don’t get involved in open source projects [&hellip;]</p> <figure class="wp-block-image size-full"><img alt="" height="550" loading="lazy" sizes="(min-width: 926px) 926px, 100vw" src="https://res.cloudinary.com/canonical/image/fetch/f_auto,q_auto,fl_sanitize,c_fill,w_926/https%3A%2F%2Fubuntu.com%2Fwp-content%2Fuploads%2F0163%2FTemplate_-Streamline-Open-Source-Design-Contributions.png" srcset="https://res.cloudinary.com/canonical/image/fetch/f_auto,q_auto,fl_sanitize,c_fill,w_460/https%3A%2F%2Fubuntu.com%2Fwp-content%2Fuploads%2F0163%2FTemplate_-Streamline-Open-Source-Design-Contributions.png 460w, https://res.cloudinary.com/canonical/image/fetch/f_auto,q_auto,fl_sanitize,c_fill,w_620/https%3A%2F%2Fubuntu.com%2Fwp-content%2Fuploads%2F0163%2FTemplate_-Streamline-Open-Source-Design-Contributions.png 620w, https://res.cloudinary.com/canonical/image/fetch/f_auto,q_auto,fl_sanitize,c_fill,w_1036/https%3A%2F%2Fubuntu.com%2Fwp-content%2Fuploads%2F0163%2FTemplate_-Streamline-Open-Source-Design-Contributions.png 1036w, https://res.cloudinary.com/canonical/image/fetch/f_auto,q_auto,fl_sanitize,c_fill,w_1681/https%3A%2F%2Fubuntu.com%2Fwp-content%2Fuploads%2F0163%2FTemplate_-Streamline-Open-Source-Design-Contributions.png 1681w, https://res.cloudinary.com/canonical/image/fetch/f_auto,q_auto,fl_sanitize,c_fill,w_926/https%3A%2F%2Fubuntu.com%2Fwp-content%2Fuploads%2F0163%2FTemplate_-Streamline-Open-Source-Design-Contributions.png 926w" width="926"/></figure> <p>As designers working at Canonical, we’re always thinking about open source. We believe that encouraging more designers to contribute to open source  benefits everyone, from the project maintainers to the end users themselves.  </p> <p>In the 2025 edition of FOSSBackstage conference, we presented our research findings on  <a href="https://www.youtube.com/watch?v=5kq2emKppSc&amp;list=PLq-odUc2x7i-vFcBUZoDxTz9Vyu0Joq0X&amp;index=46">why designers don’t get involved in open source projects </a>and found a particular breakdown between designers and project maintainers. </p> <p>The truth is that designers often struggle to find projects they can contribute to. When they do find a project, the design requirements often are unclear or very limited. Meanwhile, project maintainers struggle to articulate their design needs or may not even know when to ask for design support. </p> <p>To bridge this gap, we created a <a href="https://drive.google.com/open?id=11kQqpy4WqvqYDe9VS547uoTI4CfXriaBhTQMhYR5uo0">template for a design contribution brief for open source projects.</a> This template will help maintainers to clearly articulate their needs and give designers the essential information they need to contribute. </p> <h2 class="wp-block-heading">What’s in the contribution brief?</h2> <p>The brief has 5 sections, one for each area that can cause friction when maintainers try to onboard a designer to a project. The brief includes questions and examples that help maintainers add context to their contribution requirements, so a designer can pick up a project more easily. Here’s what each section covers:</p> <ol> <li><strong>About the project: </strong>enables maintainers to get designers up to speed with a project overview, vision, target audience, and progress tracking. This section ensures everyone is on the same page about the project’s goals and context.</li> <li><strong>About the design contribution needed:</strong> here’s where you detail the specific design contributions – from UX and UI, to graphic design and accessibility audits. Explain why you need the contribution, what user needs are, and what design skills are essential.</li> <li><strong>Logistics</strong>: outline deadlines, priority levels, and timelines to keep everyone organized and on track.</li> <li><strong>Team</strong>: introduce the project team and their roles, highlight any existing designers or contributors.</li> <li><strong>Communications: </strong>specify how the team communicates (for example, asynchronously, synchronously), preferred communication platforms, preferred language, and any support for onboarding contributors.</li> </ol> <h2 class="wp-block-heading">Why use the contribution brief?</h2> <h3 class="wp-block-heading">Benefits for project maintainers:</h3> <ol> <li><strong>Set clear expectations:</strong> the template breaks down project expectations to help maintainers articulate what they’re really looking for, and help designers understand the expectations. This makes it easier to communicate design needs and expectations to potential contributors.</li> <li><strong>Streamline your process:</strong> adding all the information to a centralized place makes it easy to reference and saves time and effort. The template addresses the most commonly asked questions, which reduces the need to repeat the same things in different channels. </li> <li><strong>Attract the right contributors:</strong> clearly articulating design needs helps attract people with the right skills and experience. Maintainers can tag their issues with specific labels and maximize their chance to reach the right audience.</li> </ol> <h3 class="wp-block-heading">Benefits for designers:</h3> <ol> <li><strong>Understand the project:</strong> designers can quickly grasp the project’s vision, goals, and target audience, without getting in touch or looking for information in more than one place.</li> <li><strong>Know your requirements:</strong> a specific scope makes it easier to know where to start and how much work will need to be done. The template helps clarify what design contributions are required and the expected outcomes.</li> <li><strong>Streamline your onboarding:</strong> the template makes it easier to understand how the team communicates and where designers can get support quickly.</li> </ol> <h2 class="wp-block-heading">How to use the template</h2> <p><a href="https://drive.google.com/open?id=11kQqpy4WqvqYDe9VS547uoTI4CfXriaBhTQMhYR5uo0">Open the template</a>, make a copy and attach it to your project. We will continue to refine the<a href="https://drive.google.com/open?id=11kQqpy4WqvqYDe9VS547uoTI4CfXriaBhTQMhYR5uo0"> template</a>, so try it out and <a href="https://canonical.design/sauce">tell us what you thought</a>.<br/><br/></p> <p></p> <hr class="wp-block-separator has-alpha-channel-opacity"/> <h3 class="wp-block-heading"><strong>Join the Canonical design team</strong></h3> <p>We’re looking for designers who care about craft and how systems work under the hood. At Canonical, design sits at the intersection of UX, engineering, and open source where we shape cohesive, accessible experiences across cloud, desktop, and IoT products.</p> <p>If you enjoy solving complex problems and turning technical depth into clarity, explore our open roles: <strong><a href="https://canonical.com/careers/web-and-design" rel="noreferrer noopener" target="_blank">canonical.com/careers</a></strong></p> Nina Rojc (Nina Rojc)Designopen designOpen sourceTue, 16 Jun 2026 13:09:44 +0000https://ubuntu.com//blog/responding-to-a-new-threat-landscape<p>Canonical&#8217;s security philosophy has always been built on the premise that vulnerabilities exist and will be discovered. Our response relies on defense-in-depth architecture, rapid patch deployment, and strict adherence to Coordinated Vulnerability Disclosure (CVD). AI changes vulnerability discovery volume and speed. We have a robust vulnerability management process that is backed by rigorous compliance certifications. [&hellip;]</p> <p>Canonical’s security philosophy has always been built on the premise that vulnerabilities exist and will be discovered. Our response relies on defense-in-depth architecture, rapid patch deployment, and strict adherence to Coordinated Vulnerability Disclosure (CVD).</p> <p>AI changes vulnerability discovery volume and speed. We have a robust vulnerability management process that is backed by <a href="https://trust.canonical.com/">rigorous compliance certifications</a>. These processes have demonstrated robustness in stringent ecosystems and we are adapting them with more exposure mapping, better customer guidance, and clearer remediation paths. This is where AI makes our customer service and internal responses more efficient.</p> <p>To address real-world security we contain the blast radius of newly weaponized legacy bugs using our historically proven confinement tools, enforcing strict kernel-level boundaries with AppArmor and native container isolation (LXD). Building on this securely-designed foundation, we continue to modernize and harden Ubuntu by championing memory-safe languages like Rust.</p> <p>We align our multi-tiered risk model with upcoming compliance requirements like the EU Cyber Resilience Act (CRA) focusing on actual threat impact rather than blindly chasing raw CVSS scores. Because AI will continuously unearth decades-old dormant flaws, we secure this foundation and your long-term compliance with up to 15 years of security maintenance through Ubuntu Pro.</p> <p>Additionally, through the <a href="https://canonical.com/blog/canonical-announces-ubuntu-security-research-alliance-program">Ubuntu Security Research Alliance Program</a> we’re partnering directly with leading security scanning providers in order to improve how accurately our data is presented in scan results, and to ensure that every piece of open source software distributed by Canonical is properly assessed. </p> <p><strong>1. What is Canonical’s  current awareness of the Mythos / Glasswing CVE disclosure? </strong></p> <p>Canonical’s Security Team is transforming its processes and infrastructure to adapt to the scale and speed of new frontier models, such as Mythos, GPT-5.5, and open-weight models. This ensures our incident response teams are fully prepared to triage and remediate the anticipated influx of AI-generated vulnerability reports.</p> <p><strong>2. Has Canonical conducted any internal AI-assisted vulnerability analysis across its own product estate?</strong> </p> <p>Yes, we are actively integrating agentic <a href="https://ubuntu.com/blog/finding-the-blind-spot-how-canonical-hunts-logic-flaws-with-ai">AI frameworks to conduct independent vulnerability analysis across our estate</a>. This evolution builds directly on our strict, foundational <a href="https://ubuntu.com/blog/canonicals-commitment-to-quality-management">quality management practices</a>, such as the extensive package auditing required by our <a href="https://documentation.ubuntu.com/project/MIR/main-inclusion-review/">Main Inclusion Review process</a>.</p> <p><strong>3. Do you have a list of products that you would consider most exposed to the latest frontier-model vulnerability categories?</strong> </p> <p>Because the foundational Linux stack is historically written in non-memory-safe C/C++, exposure to these classes of vulnerabilities is systemic across the entire open source ecosystem. Rather than maintaining a flat, theoretical “exposed list,” Canonical mitigates these risks structurally. First, we enforce <a href="https://documentation.ubuntu.com/security/security-features/process-memory/compiler-flags">mandatory compiler-level protections that go hand in hand with Linux kernel features for application hardening</a> across the entire Ubuntu archive to reduce exploitability.</p> <p>Furthermore, we evaluate exposure and prioritize our engineering response through a multi-layered risk model, ensuring that a massive influx of AI-discovered CVEs does not lead to a panicked, one-size-fits-all response. Instead, we right-size our response based on the component at hand:</p> <ul> <li>Critical Foundation: Core components that could have significant impact on a system. This includes the <em>kernel, glibc, OpenSSL, systemd, sudo, PAM</em>, and core <em>container runtimes</em>.</li> <li>Infrastructure &amp; Orchestration: Canonical’s management, isolation, and deployment layers. This includes <em>snapd, AppArmor, cloud-init, LXD, MAAS, Juju, and MicroK8s</em>. These tools govern how the infrastructure is secured and scaled.</li> <li>Application Ecosystem: The thousands of open-source applications and dependencies residing in the <em>Universe</em> repository, which are covered under Ubuntu Pro. While an AI-discovered CVE here might impact a specific business service, the threat might be contained by the structural protections (like AppArmor) established by the tiers above it.</li> </ul> <p>and</p> <ul> <li>Custom Workloads: Customer-specific applications and proprietary code operating outside of Canonical’s scope.</li> </ul> <p><strong>4. What is Canonical’s typical turnaround time for releasing CVE fixes, and how do you prioritize which vulnerabilities get patched first?</strong></p> <p>While we do not treat every vulnerability with a uniform SLA, our focus is on rapid remediation for high-risk threats. We aim to prepare, test, and release the most vital security updates within 24 hours on average.</p> <p>In the event of a true zero-day vulnerability or evidence of active exploitation in the wild, we push expedited, emergency fixes to our users as fast as possible.</p> <p>Because we understand that not all CVEs carry the same real-world risk, we do not prioritize fixes based strictly on raw CVSS scores. Instead, we triage vulnerabilities based on their specific impact on Ubuntu users. Fixes are expedited for vulnerabilities that present the highest actual risk and affect the largest number of installations, ensuring that your most critical systems receive protection first.</p> <p><strong>5. Where a software patch cannot be deployed within the required window, what compensating controls or virtual patching capabilities does Canonical have available?</strong> </p> <p>Ubuntu’s default implementation of AppArmor profiles and snap confinement act as strict structural compensating controls, isolating vulnerable services and protecting against privilege escalation or arbitrary file access. Kernel Livepatch applies permanent kernel vulnerability fixes in-memory without requiring a system reboot.</p> <p>Furthermore, in instances where a formal fix is not yet available, we aim to provide clear, actionable mitigation strategies – such as specific system workarounds or configuration changes – directly on our CVE trackers (e.g., our published mitigations for<a href="https://ubuntu.com/security/CVE-2022-23960#mitigation"> CVE-2022-23960</a>) to help you secure your environment in the interim. </p> <p>Finally, we frequently publish detailed <a href="https://ubuntu.com/blog/apparmor-vulnerability-fixes-available">blog posts</a> breaking down the vulnerabilities, including impact assessments, real-world scenarios, and potential mitigations, to help our users fully understand the risk and secure their environments.</p> <p><strong>6. What is Canonical’s responsible disclosure process for Glasswing-identified vulnerabilities in your products? </strong></p> <p>Canonical does not maintain a separate, specialized vulnerability management process specifically for Project Glasswing. Consequently, we do not provide exclusive early notifications, out-of-band updates, or bypass standard community embargoes for individual partners prior to the Coordinated Release Date (CRD). We adhere to the best-practices recognized by the security community in Coordinated Vulnerability Disclosure (CVD) and we handle embargoes according to our <a href="https://ubuntu.com/security/disclosure-policy">Disclosure Policy</a>.</p> <p>Canonical’s Security Team ensures that patches are actively developed, thoroughly tested, and pre-staged within the standard embargo window. These fixes are released globally and simultaneously with the public CVE disclosure, ensuring our customers and partners can confidently deploy updates at “day zero.”</p> <p><strong>7. How is Canonical evolving its development and architectural practices to defend against the class of vulnerabilities that Mythos-like projects uncover?</strong></p> <p>Canonical is actively modernizing its products to address decades-old paradigms. We are championing the integration of memory-safe languages into the core OS by enabling Rust support in our kernels and providing the complete toolchain for developers. We encourage the community to build in Rust, and our own engineering efforts are focused on rewriting critical user-space components. </p> <p>For legacy C/C++ code that cannot be immediately rewritten, we rely on defense-in-depth. Assuming legacy code will inevitably have flaws, we engineer the Ubuntu environment to prevent those logic flaws from becoming viable, chained exploits. </p> <p>To achieve this, Ubuntu natively supports robust isolation technologies like snaps and LXD. When users wrap their legacy applications in these secure sandboxed environments, strict kernel-level boundaries – such as cgroups, namespaces, and AppArmor profiles – are enforced, ensuring that even if a legacy application is compromised, the blast radius is tightly contained and the underlying host remains protected.</p> <p><strong>8. Does the advent of Glasswing mean previously secure Ubuntu systems are now suddenly vulnerable?</strong></p> <p>The threat landscape timelines are compressing. AI tools are unearthing “N-days” and legacy logic errors that survived conventional human review. </p> <p>However, a vulnerability does not automatically equal a system compromise. Canonical’s fundamental security architecture, leveraging AppArmor confinement, minimal yet comprehensive images, strict namespace isolation, and proactive memory protections, was specifically designed on the assumption that zero-days and undiscovered flaws will always exist. This defense-in-depth approach is built to tightly contain the “blast radius” when a dormant bug is suddenly weaponized, preventing an attacker from escalating a single flaw into full system control.</p> <p>Because AI will inevitably accelerate the volume of these historical bugs coming to light, the speed and duration of your patching lifecycle is more critical than ever. Ubuntu Pro provides up to 15 years of security maintenance and support. This ensures that when a decades-old vulnerability is suddenly surfaced with a working exploit, your infrastructure receives rapid, tested patches for years to come, without forcing you into disruptive, premature upgrades.</p> <p><strong>9. Is Canonical a direct participant in Anthropic’s Project Glasswing or actively using Claude Mythos?</strong></p> <p>Canonical is currently not a direct participant in Project Glasswing. We engage with all major security initiatives through our established Coordinated Vulnerability Disclosure (CVD) processes. We do not bypass these protocols or grant exclusive early access to any single AI vendor or participant. Our priority is taking security and vulnerability disclosures seriously, independent of the reporting source.</p> <p><strong>10. What happens if Canonical receives a severe vulnerability report that comes from an AI or model-based discovery tool?</strong></p> <p>We evaluate the technical merit of the finding, regardless of the entity or method that found it. If an AI tool discovers a severe vulnerability, Canonical conducts a risk assessment based on the specific environmental context of the open source project, and the actual exploitability of the bug. </p> <p><strong>11. How should researchers or partners report vulnerabilities they discover in Ubuntu using AI tools?</strong></p> <p>Our process is governed by the official<a href="https://ubuntu.com/security/disclosure-policy"> Ubuntu Security Disclosure Policy</a>. Canonical Security Team participate in responsible disclosure and collaborate closely with the wider open-source community.</p> <p>When a vulnerability is identified (whether internally, by a partner, or through a researcher, using AI or not), our protocol is as follows:</p> <ul> <li>Initial Response: We prioritize rapid assessment and prompt initial response to security reporters. </li> <li>CVE Assignment: Canonical acts as a CVE Numbering Authority (CNA) and can directly assign CVE numbers.</li> <li>Embargo Adherence: Canonical’s Security Team manages embargo vulnerabilities in coordination with the broader open source community. For issues that are not yet publicly known, we strictly abide by agreed-upon timelines and information-handling. This ensures patches can be safely developed and released simultaneously with the public announcement (“day zero”) without tipping off malicious actors.</li> <li>Emergency Releases: We reserve the right to release fixes immediately if there is evidence of an embargo being broken that leads to a significant risk to our users.</li> <li>Transparency: All Ubuntu vulnerabilities fixed by Canonical’s Security Team are publicly documented and credited via Ubuntu Security Notices (USNs), ensuring our customers have a clear, auditable trail of our security interventions.</li> <li>Accuracy: Information on all vulnerabilities affecting Ubuntu is distributed through industry-standard machine-readable data feeds: <a href="https://documentation.ubuntu.com/security/security-updates/osv/">OSV</a>, <a href="https://documentation.ubuntu.com/security/security-updates/vex/">VEX</a>, and <a href="https://documentation.ubuntu.com/security/security-updates/oval/">OVAL</a>.</li> </ul> Lech Sandecki (Lech Sandecki)Tue, 16 Jun 2026 11:45:26 +0000https://ubuntu.com//blog/ubuntu-core-26-ai-box<p>Welcome to this blog series which explores innovative uses of Ubuntu Core. Throughout this series, Canonical’s Engineers will show what you can build with this Core 26 release, highlighting the features and tools available to you.&nbsp; In this first blog, Farshid Tavakolizadeh, Engineer Manager for Canonical’s Industrial team, will show you how to try Ubuntu [&hellip;]</p> <p>Welcome to this blog series which explores innovative uses of Ubuntu Core. Throughout this series, Canonical’s Engineers will show what you can build with this Core 26 release, highlighting the features and tools available to you. </p> <p>In this first blog, <a href="mailto:farshid.tavakolizadeh@canonical.com">Farshid Tavakolizadeh</a>, Engineer Manager for Canonical’s Industrial team, will show you how to try Ubuntu Core 26 inside a virtual machine and turn it into a local AI inference appliance using Multipass and the gemma4 snap. Running Ubuntu Core in a VM is a useful starting point for developers who want to experiment before moving to dedicated hardware. You can explore the Ubuntu Core environment, install snaps, expose services to your host machine, and test how an appliance-style experience could work in production.</p> <p>By the end of this blog, you’ll know how to launch Ubuntu Core 26 with Multipass, install a local AI inference snap, access its WebUI from your host machine, and understand how this workflow maps to a production Ubuntu Core image.</p> <h2 class="wp-block-heading">Why start with Ubuntu Core in a VM?</h2> <p>Ubuntu Core is designed for production devices: appliances, gateways, robots, kiosks, industrial systems, and edge AI products. In the field, you would normally <a href="https://documentation.ubuntu.com/core/tutorials/build-your-first-image/">build a custom Ubuntu Core</a> image that includes the snaps, configuration, permissions, and update policy your product needs.</p> <p>A virtual machine gives you a fast way to explore the system. You can launch Ubuntu Core from your laptop, install application snaps, test services, and understand how the pieces fit together before committing to a board or production image.</p> <p>For this, Multipass provides a simple path. It has integrated support for Ubuntu Core images and can launch an Ubuntu Core VM with a single command. That makes it ideal for experimentation, demos, and local development workflows.</p> <h2 class="wp-block-heading">Turning the VM into a local AI appliance</h2> <p>We will use Ubuntu Core to create a local AI inference appliance. The idea is simple: Ubuntu Core provides the secure, minimal, appliance-like operating system, while the AI workload is delivered as a snap.</p> <p>For this example, we’ll use the gemma4 inference snap.</p> <p>Because AI inference needs more resources than a minimal shell test, launch a VM with additional CPU, memory, and disk:</p> <pre class="wp-block-code"><code>multipass launch core26 -n aibox --cpus 4 --memory 10GB --disk 16GB</code></pre> <p>Then enter the instance:</p> <pre class="wp-block-code"><code>multipass shell aibox</code></pre> <p>The Ubuntu Core instance may update itself after first boot, and it may restart automatically. This is part of the experience you should expect from Ubuntu Core: the base system and snapd are managed, updated, and kept reliable.</p> <p>Now install the AI inference snap:</p> <pre class="wp-block-code"><code>sudo snap install gemma4</code></pre> <p>This installs the most suitable runtime and model for the machine.</p> <h2 class="wp-block-heading"><strong>Checking the inference endpoint</strong></h2> <p>Once installed, gemma4 runs as a managed snap service. You can check its status with:</p> <pre class="wp-block-code"><code>gemma4 status</code></pre> <p>The output includes the active engine, services, and endpoints:</p> <pre class="wp-block-code"><code>engine: cpu services:    server: active    server-webui: active endpoints:    openai: http://localhost:8336/v1    webui: http://localhost:8337/</code></pre> <p>At this point, the inference server and WebUI are running inside the Ubuntu Core instance.</p> <p>There is one important detail: localhost here refers to the Ubuntu Core VM, not your host machine. So while the service is active, your browser on your laptop cannot necessarily access it yet.</p> <p>To make the inference server and WebUI available from the host, configure the service to listen on the VM’s network interface:</p> <pre class="wp-block-code"><code>sudo gemma4 set http.host=0.0.0.0 webui.http.host=0.0.0.0 --assume-yes</code></pre> <p>Then, from your host machine, find the VM’s IP address:</p> <pre class="wp-block-code"><code>multipass info aibox</code></pre> <p>The output includes an IPv4 address:</p> <pre class="wp-block-code"><code>Name:           aibox State:          Running Snapshots:      0 IPv4:           10.100.120.150 Release:        Ubuntu Core 26</code></pre> <p>Use the IPv4 address to access the inference server and WebUI, in this case: 10.100.120.150.</p> <p>The inference server’s API is accessible at http://&lt;VM’s IPv4&gt;:8336/v1. This is an OpenAI compliant API that can be used with a wide range of clients. You can use an HTTP client like cURL to make a prompt:</p> <pre class="wp-block-code"><code>curl http://10.100.120.150:8336/chat/completions -H "Content-Type: application/json" -d '{ "messages": [{"role": "user", "content": "What is the meaning of ubuntu?"}], "max_completion_tokens": 100 }'</code></pre> <p>Of course, experimenting with an OpenAI API over the terminal is no fun. The WebUI that is provided by the gemma4 snap is a better entry point to try. Open in your browser: http://10.100.120.150:8337</p> <figure class="wp-block-image size-full"><img alt="" height="1420" loading="lazy" sizes="(min-width: 1894px) 1894px, 100vw" src="https://res.cloudinary.com/canonical/image/fetch/f_auto,q_auto,fl_sanitize,c_fill,w_1894/https%3A%2F%2Fubuntu.com%2Fwp-content%2Fuploads%2F3ab8%2Fimage.png" srcset="https://res.cloudinary.com/canonical/image/fetch/f_auto,q_auto,fl_sanitize,c_fill,w_460/https%3A%2F%2Fubuntu.com%2Fwp-content%2Fuploads%2F3ab8%2Fimage.png 460w, https://res.cloudinary.com/canonical/image/fetch/f_auto,q_auto,fl_sanitize,c_fill,w_620/https%3A%2F%2Fubuntu.com%2Fwp-content%2Fuploads%2F3ab8%2Fimage.png 620w, https://res.cloudinary.com/canonical/image/fetch/f_auto,q_auto,fl_sanitize,c_fill,w_1036/https%3A%2F%2Fubuntu.com%2Fwp-content%2Fuploads%2F3ab8%2Fimage.png 1036w, https://res.cloudinary.com/canonical/image/fetch/f_auto,q_auto,fl_sanitize,c_fill,w_1681/https%3A%2F%2Fubuntu.com%2Fwp-content%2Fuploads%2F3ab8%2Fimage.png 1681w, https://res.cloudinary.com/canonical/image/fetch/f_auto,q_auto,fl_sanitize,c_fill,w_1920/https%3A%2F%2Fubuntu.com%2Fwp-content%2Fuploads%2F3ab8%2Fimage.png 1920w, https://res.cloudinary.com/canonical/image/fetch/f_auto,q_auto,fl_sanitize,c_fill,w_1894/https%3A%2F%2Fubuntu.com%2Fwp-content%2Fuploads%2F3ab8%2Fimage.png 1894w" width="1894"/></figure> <p>You can also integrate the API with a tool such as Open WebUI or OpenCode to do more.</p> <p>You now have an AI inference interface running inside Ubuntu Core.</p> <h2 class="wp-block-heading">What this demonstrates</h2> <p>This example may be running in a VM, but the architecture is the same pattern used for real devices.</p> <p>The Ubuntu Core base system remains separate from the application workload. The AI server is delivered as a snap. The WebUI is delivered as a managed service. The inference endpoint runs inside the Ubuntu Core environment. Configuration is applied through snap options rather than by manually editing system files.</p> <p>In other words, you are not just installing a package. You are assembling the foundations of an appliance.</p> <p>This matters because production devices are rarely managed one command at a time. A finished product needs a predictable boot experience, controlled services, reliable updates, and a clear boundary between the operating system and the application layer.</p> <p>Ubuntu Core provides that boundary.</p> <h2 class="wp-block-heading">From local experiment to production image</h2> <p>Installing gemma4 manually is useful for development, but it is not how you would normally ship a product.</p> <p>In a production deployment, the AI snap and its configuration would typically be included in a custom Ubuntu Core image. That image would be described by a model assertion, which defines the snaps that make up the device image, including required or optional application snaps.</p> <p>With that approach, the device starts directly into the experience you designed.</p> <p>Your users do not need to install the snap manually. They do not need to log into the Core instance. They do not need to understand how the inference endpoint is configured. The product boots with the right snaps, services, permissions, and defaults already in place.</p> <p>This is where Ubuntu Core becomes especially powerful. The same workflow you tested in a VM can evolve into a repeatable product image for hardware, production lines, demos, customer pilots, or fleet deployments.</p> <h2 class="wp-block-heading">Managing appliances over time</h2> <p>Once a device is deployed, the work is not finished.</p> <p>You may want to update the AI model, fix a CVE in the inference server, adjust configuration, or deploy the same image to different customers with different workloads.</p> <p>Ubuntu Core is designed for this lifecycle. Application snaps can be updated independently from the base system. Updates are transactional. If something goes wrong, the system can roll back to a known good state.</p> <p>For larger deployments, snaps can also be installed, configured, and managed through fleet management. <a href="https://ubuntu.com/landscape">Landscape</a> provides centralized administration for Ubuntu deployments, including IoT devices.</p> <p>This gives developers a flexible path: build the experience into the image from day one, or manage and evolve application snaps later across a fleet.</p> <h2 class="wp-block-heading">What’s next?</h2> <p>With Multipass, you can launch a Core VM in minutes. With snaps, you can install and manage real workloads. With gemma4, you can turn that VM into a local AI inference appliance that exposes both an API endpoint and a web server.</p> <p>This is a small example, but it shows the larger pattern.</p> <p>You can separate your application from the base system. You can run services in a managed way. You can configure the product experience. And when you are ready, you can move from a pre-built VM image to a custom Ubuntu Core image defined by your own model assertion.</p> <p>Below are some useful links for further reading:</p> <ul> <li><a href="https://documentation.ubuntu.com/inference-snaps/">Discover inference snaps</a></li> <li><a href="https://ubuntu.com/blog/getting-started-with-azure-iot-edge-on-ubuntu-core">Getting started with AWS IoT Greengrass on Ubuntu Core</a></li> <li><a href="https://canonical.com/blog/tutorial-getting-started-with-aws-greengrass-on-ubuntu-core">Getting Started with Azure IoT Edge on Ubuntu Core</a></li> </ul> Gabriel Aguiar Noury (Gabriel Aguiar Noury)AIIoTUbuntu CoreTue, 16 Jun 2026 09:08:09 +0000https://ubuntu.com//blog/a-decade-of-ubuntu-on-ibm-z-and-ibm-linuxone<p>This year we celebrate a decade of Ubuntu Server support on the s390x architecture: marking a long-standing collaboration between Canonical and IBM that began at LinuxCon 2015. The first release happened on April 21, 2016, bringing Ubuntu 16.04 LTS (Xenial Xerus) to IBM Z and IBM LinuxONE platforms.  A first for Ubuntu on IBM That [&hellip;]</p> <figure class="wp-block-image size-full"><img alt="" height="800" loading="lazy" sizes="(min-width: 1920px) 1920px, 100vw" src="https://res.cloudinary.com/canonical/image/fetch/f_auto,q_auto,fl_sanitize,c_fill,w_1920/https%3A%2F%2Fubuntu.com%2Fwp-content%2Fuploads%2F6c03%2FIBM-10Y-Blog-Presentation-1.png" srcset="https://res.cloudinary.com/canonical/image/fetch/f_auto,q_auto,fl_sanitize,c_fill,w_460/https%3A%2F%2Fubuntu.com%2Fwp-content%2Fuploads%2F6c03%2FIBM-10Y-Blog-Presentation-1.png 460w, https://res.cloudinary.com/canonical/image/fetch/f_auto,q_auto,fl_sanitize,c_fill,w_620/https%3A%2F%2Fubuntu.com%2Fwp-content%2Fuploads%2F6c03%2FIBM-10Y-Blog-Presentation-1.png 620w, https://res.cloudinary.com/canonical/image/fetch/f_auto,q_auto,fl_sanitize,c_fill,w_1036/https%3A%2F%2Fubuntu.com%2Fwp-content%2Fuploads%2F6c03%2FIBM-10Y-Blog-Presentation-1.png 1036w, https://res.cloudinary.com/canonical/image/fetch/f_auto,q_auto,fl_sanitize,c_fill,w_1681/https%3A%2F%2Fubuntu.com%2Fwp-content%2Fuploads%2F6c03%2FIBM-10Y-Blog-Presentation-1.png 1681w, https://res.cloudinary.com/canonical/image/fetch/f_auto,q_auto,fl_sanitize,c_fill,w_1920/https%3A%2F%2Fubuntu.com%2Fwp-content%2Fuploads%2F6c03%2FIBM-10Y-Blog-Presentation-1.png 1920w" width="1920"/></figure> <p>This year we celebrate a decade of Ubuntu Server support on the s390x architecture: marking a long-standing collaboration between Canonical and IBM that began at <a href="https://ubuntu.com/blog/ibm-and-canonical-plan-ubuntu-support-on-ibm-z-systems-mainframe" rel="noreferrer noopener" target="_blank">LinuxCon 2015</a>. The first release happened on April 21, 2016, bringing Ubuntu 16.04 LTS (Xenial Xerus) to IBM Z and IBM LinuxONE platforms. </p> <h2 class="wp-block-heading">A first for Ubuntu on IBM</h2> <p>That release was a significant milestone: for the first time, enterprises could deploy the vast Ubuntu ecosystem directly on IBM hardware. IBM Z and IBM LinuxONE platforms handle a significant portion of the world’s financial transactions, and power critical banking and healthcare systems. Native support ensured Ubuntu’s availability and long term sustainability for development and production workloads from day one, in environments that have some of the strictest security requirements.</p> <h3 class="wp-block-heading"><strong>Engineering for architecture parity</strong></h3> <p>Canonical’s partnership with IBM allows organizations to modernize their mission-critical systems by bringing the Ubuntu developer ecosystem and Canonical’s enterprise support to IBM mainframes. </p> <p>Through this collaboration, large enterprises can freely adopt open source tools and technologies. For example, Canonical provides <a href="https://ubuntu.com/server" rel="noreferrer noopener" target="_blank">Ubuntu Server</a> images for traditional installations, <a href="https://cloud-images.ubuntu.com/" rel="noreferrer noopener" target="_blank">cloud images</a> for KVM, OpenStack, LXD, and other virtualized environments, as well as <a href="https://hub.docker.com/u/ubuntu" rel="noreferrer noopener" target="_blank">OCI images</a> for cloud native environments. This makes it easier for developers and organizations to develop applications on a different architecture, porting them to the IBM platform once it’s time to go to production.</p> <p>Ubuntu supports multiple deployment modes on IBM Z and IBM LinuxONE, including:</p> <ul> <li>LPAR (logical partitions)</li> <li>z/VM virtualization</li> <li>KVM</li> <li>LXD and OCI containers</li> </ul> <p>These deployment models enable enterprises to efficiently run a large number of isolated Linux workloads on the same physical system,<strong> </strong>a core advantage of IBM’s scale-up architecture<strong>. </strong>In environments where servers are often underutilized, this improves resource utilization, addressing common challenges such as data center sprawl, rising power costs and server consolidation needs.</p> <h2 class="wp-block-heading">How we partner to bring Ubuntu to more architectures</h2> <p>Ensuring a consistent Ubuntu experience in new systems, hardware and architectures requires dedication. To achieve this, our engineers work closely with both IBM and upstream developers to avoid forks and maintain high software quality. Some of the key highlights from our decade of collaboration include:</p> <ul> <li>Maintaining s390-tools from version 1.34.0 to 2.41.0</li> <li>Delivering early support for Secure Boot on IBM Z and LinuxONE</li> <li>Enabling IBM Secure Execution (TEE) to protect data in use</li> </ul> <p>At the same time, Canonical:</p> <ul> <li>Ships a new version of Ubuntu every 6 months, and an LTS version every 2 years</li> <li>Provides <a href="https://ubuntu.com/blog/canonical-expands-total-coverage-for-ubuntu-lts-releases-to-15-years-with-legacy-add-on" rel="noreferrer noopener" target="_blank">up to 15 years</a> of support for LTS releases, one of the longest support life cycles in the market</li> <li>Maintains thousands of open source packages in a constantly growing ecosystem</li> </ul> <h3 class="wp-block-heading"><strong>Why should you use Ubuntu in your enterprise?</strong></h3> <p>Ubuntu brings world-class open source software and enterprise-grade security and stability for the widest range of applications, use cases and industries. Through this partnership, IBM integrates Ubuntu as a strategic part of it’s ecosystem, providing a high-performance, secure, and efficient foundation for mission-critical workloads on IBM Z and IBM LinuxONE.</p> <p>Here are some core reasons why Ubuntu excels in enterprise environments:</p> <ul> <li><strong>Pervasive security: </strong>complements IBM hardware with support for Secure Execution (TEE) and end-to-end encryption for data at rest and in use</li> <li><strong>Maximum uptime:</strong> supports features like <a href="https://ubuntu.com/security/livepatch" rel="noreferrer noopener" target="_blank">Kernel Livepatch</a> allowing critical updates to be applied between maintenance windows, eliminating disruptive downtime</li> <li><strong>Streamlined compliance: </strong>simplifies regulatory requirements for the public sector through built-in support for FIPS and other industry certifications</li> <li><strong>Future-proof cryptography:</strong> integrates quantum-safe algorithms (ML-KEM and ML-DSA) via the Crypto Express 8S module to protect against evolving digital threats</li> <li><strong>Expanded security maintenance: </strong>with <a href="https://ubuntu.com/pro" rel="noreferrer noopener" target="_blank">Ubuntu Pro</a>, organizations get long-term stability with security patches for thousands of open source packages.</li> </ul> <h3 class="wp-block-heading"><strong>AI future-ready</strong></h3> <p>Canonical is also working with IBM to ensure Ubuntu Server fully leverages the latest hardware technologies from IBM, including the IBM Telum® II processor and the IBM Spyre™ Accelerator. In that context, Ubuntu serves as the foundational ecosystem for modern AI development on IBM Z and IBM LinuxONE, bridging the gap between raw compute, multi-platform support, enterprise scale, and production-ready AI workloads. With a consistent environment across workstations and clouds, engineers and researchers can quickly transition from development to large-scale training and inferencing. </p> <h2 class="wp-block-heading">What the future holds</h2> <p>It has been a successful 10 years with significant technical advancements, and we look forward to the next decade, and more. This collaboration has established a reliable path for enterprises to run Linux and Ubuntu on IBM infrastructure.</p> <p>Today, Ubuntu continues to be fully certified across multiple generations of IBM Z and IBM LinuxONE systems, including IBM z17 and IBM LinuxONE 5, ensuring compatibility with modern enterprise hardware and cryptographic capabilities. As enterprise needs shift toward AI workloads, hybrid cloud architectures, and quantum-safe security, our unified stack provides the foundation required for the next decade of mission-critical computing.</p> <p><a href="https://ubuntu.com/download/server/s390x" rel="noreferrer noopener" target="_blank">Download Ubuntu Server for IBM Z and LinuxONE</a></p> <p><a href="http://www.ibm.com/linuxone" rel="noreferrer noopener" target="_blank">Visit the IBM LinuxONE page</a></p> <p>Or if you have any questions, <a href="https://ubuntu.com/ibm#get-in-touch" rel="noreferrer noopener" target="_blank">contact us directly</a>.</p> Pedro Lazzarotto (Pedro Lazzarotto)IBMIBM LinuxONEIBM ZInfrastructurePartnerServerUbuntuFri, 12 Jun 2026 18:13:30 +0000https://ubuntu.com//blog/ai-at-the-edge-simplifying-infrastructure-with-cisco-and-canonical<p>Legacy infrastructure was not designed for the requirements of the AI era. While large-scale model training remains centralized in data centers, test-time inference is rapidly shifting to the edge to reduce latency and bandwidth consumption. This shift creates a new frontier for enterprise AI, but deploying at the edge introduces significant manual complexity, interoperability issues, [&hellip;]</p> <p>Legacy infrastructure was not designed for the requirements of the AI era. While large-scale model training remains centralized in data centers, test-time inference is rapidly shifting to the edge to reduce latency and bandwidth consumption. This shift creates a new frontier for enterprise AI, but deploying at the edge introduces significant manual complexity, interoperability issues, and security vulnerabilities.</p> <p>To address these challenges, Cisco and Canonical have developed a new Cisco Validated Design (CVD). This guide details how to leverage the Canonical portfolio on the Cisco Unified Edge system to deliver scalable, secure, and cost-efficient AI-ready infrastructure. In this article, we’ll whet your appetite by highlighting the key challenges, technologies, and solutions explored in the guide.</p> <h3 class="wp-block-heading">The challenges of legacy infrastructure for AI</h3> <p>Enterprises attempting to deploy AI use cases on traditional edge infrastructure typically face five critical bottlenecks:</p> <ul> <li><strong>Hardware Limitations: </strong>Lack of specialized acceleration (GPUs) and high-density compute in small form factors.</li> <li><strong>Architectural Rigidity:</strong> Static environments that cannot easily pivot between virtualized and containerized workloads.</li> <li><strong>Scaling Inefficiency: </strong>Difficulty in managing thousands of geographically dispersed sites consistently.</li> <li><strong>Cost Prohibitions:</strong> High CapEx for “rip-and-replace” cycles and high OpEx for manual site maintenance.</li> <li><strong>Software Fragmentation:</strong> Version lag, lack of security patching (CVEs), and vendor lock-in.</li> </ul> <p>Let’s dig into how our joint solution with Cisco addresses these challenges.</p> <h3 class="wp-block-heading">The software layer: A unified open source stack</h3> <p>The solution begins with a hardened software foundation provided by Canonical. By decoupling the application layer from the underlying hardware, enterprises can modernize legacy operations without manual rebuilds.</p> <ul> <li><strong>Ubuntu Pro:</strong> Provides a stable, 15-year security maintenance lifecycle, backporting of critical fixes, and seamless public cloud integration.</li> <li><strong>Data Science Stack (DSS):</strong> A ready-to-use environment for data scientists to develop and deploy models without worrying about underlying library dependencies.</li> <li><strong>Charmed Operators: </strong>Automated operations for popular AI/ML toolkits (e.g., Kubeflow, MLflow), enabling consistent deployment and “Day 2” operations across the fleet.</li> </ul> <h3 class="wp-block-heading">The hardware layer: Converged infrastructure for AI</h3> <p>AI at the edge requires hardware that is both rugged and high-performing. The Cisco Unified Edge is a purpose-built system that converges compute, networking, storage, and security into a compact footprint.</p> <h4 class="wp-block-heading">Hardware certification</h4> <p>A key advantage of this partnership is the Canonical certification program. The Cisco UCS hardware is Ubuntu Certified, meaning Canonical works directly with Cisco to ensure the OS kernel is optimized for this specific platform. Running on this hardware, Ubuntu Server 24.04.3 LTS provides a stable, trusted open source foundation for edge applications.</p> <p>The design guide we’ve developed with Cisco utilizes the Cisco UCS XE9305 chassis, which provides a variety of features to support inference at the edge:</p> <ul> <li><strong>Form Factor:</strong> A 3-Rack-Unit (3RU) short-depth platform designed for space-constrained edge environments.</li> <li><strong>Compute Nodes: </strong>Hosts up to five Cisco UCS XE130c nodes.</li> <li><strong>Processing: </strong>6th Gen Intel Xeon SoC processors (up to 32 cores per node).</li> <li><strong>Memory:</strong> Up to 768GB DDR5 for high-throughput data processing.</li> <li><strong>Acceleration: </strong>Dedicated NVIDIA L4 Tensor Core GPUs, providing energy-efficient AI inference.</li> </ul> <h3 class="wp-block-heading">Deployment flexibility: From VMs to Kubernetes</h3> <p>Edge environments often require a mix of legacy and modern workloads. The Cisco and Canonical solution supports multiple deployment models on a single platform, solving the architectural rigidity challenge:</p> <ul> <li>System containers and VMs with <a href="https://canonical.com/lxd" rel="noreferrer noopener" target="_blank">LXD</a>: LXD treats containers like lightweight virtual machines, offering a VM-like experience with the efficiency of containers. It is ideal for hosting full Linux distributions or infrastructure services with minimal overhead.</li> <li><a href="https://ubuntu.com/kubernetes" rel="noreferrer noopener" target="_blank">Canonical Kubernetes</a>: For orchestrated, cloud-native applications, Canonical Kubernetes delivers an enterprise-grade distribution that is fully upstream-aligned.</li> <li><a href="https://canonical.com/microcloud" rel="noreferrer noopener" target="_blank">Canonical MicroCloud</a>: This lightweight, automated private cloud solution is purpose-built for resource-constrained environments. It combines LXD, MicroCeph for storage, and MicroOVN for networking into a self-managing stack.</li> </ul> <h3 class="wp-block-heading">Zero-Touch operations and security</h3> <p>Managing thousands of edge locations is an operational bottleneck. This solution utilizes Cisco Intersight, a cloud-based management platform, to enable Zero-Touch Provisioning (ZTP).</p> <p>By using curated Blueprints, administrators can automate the deployment of the entire stack, from hardware firmware to the OS and Kubernetes layers. This eliminates manual configuration errors and ensures site-to-site consistency.</p> <p>This foundation is reinforced by multi-layered protection, utilizing Ubuntu Pro for continuous CVE patching and MicroOVN to ensure network isolation for sensitive AI models and data.</p> <h3 class="wp-block-heading">Conclusion</h3> <p>The shift to edge AI demands a departure from traditional infrastructure silos. By combining Cisco’s modular, high-performance hardware with Canonical’s automated open source software stack, enterprises can build a future-ready platform that scales without the need for constant “rip-and-replace” cycles.</p> <p>Would you like to explore the full technical specifications and deployment steps?</p> <p><a href="https://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/UCS_CVDs/Cisco_Unified_Edge_and_Canonical_Ubuntu_for_Edge_Deployments_Design.html" rel="noreferrer noopener" target="_blank">Read the full Cisco Unified Edge and Canonical Design Guide</a></p> <p><strong>Or if you have any questions, <a href="https://canonical.com/contact-us#get-in-touch" rel="noreferrer noopener" target="_blank">contact us directly</a>.</strong></p> <p>Further reading:</p> <p><a href="https://documentation.ubuntu.com/server/" rel="noreferrer noopener" target="_blank">Ubuntu Server documentation</a> </p> <p><a href="https://documentation.ubuntu.com/microcloud/v2-edge/microcloud/" rel="noreferrer noopener" target="_blank">Canonical MicroCloud documentation</a></p> Pedro Lazzarotto (Pedro Lazzarotto)AIAI/ML InfrastructureCiscoEdge AIPartnerThu, 11 Jun 2026 19:25:22 +0000https://ubuntu.com//blog/the-next-era-of-telco-clouds-get-open-infrastructure-choice-with-sylva-and-canonical-kubernetes<p>Achieving vendor neutrality in telco clouds requires an infrastructure layer that respects open standards, without wrapping them in rigid platform layers. By combining upstream alignment with up to 15 years of support longevity, Canonical’s approach to Sylva is built around a requirement that matters deeply to telcos: follow upstream cloud-native innovation when developing and evolving platforms, then rely on long-term support to keep production environments stable, trusted, and operationally predictable.</p> <p>The telco industry is undergoing a fundamental change. Over the past few years, the increasing maturity of cloud-native infrastructure has accelerated the movement from manually operated and hardware-centric systems to automated, software-defined platforms. </p> <p>Underpinning this change are open source initiatives such as the <a href="https://sylvaproject.org/">Sylva project</a>. Sylva is hosted by Linux Foundation Europe and heavily backed by major telecom operators and vendors. It provides a standardized, declarative cloud-native software framework for building and operating telco infrastructures. The project aims to reduce fragmentation in telco clouds and to help telco operators break free from proprietary vendor lock-in. </p> <p>However, achieving vendor neutrality requires an infrastructure layer that respects open standards, without wrapping them in rigid platform layers. By combining upstream alignment with up to 15 years of support longevity, Canonical’s approach to Sylva is built around a requirement that matters deeply to telcos: follow upstream cloud-native innovation when developing and evolving platforms, then rely on long-term support to keep production environments stable, trusted, and operationally predictable.</p> <h2 class="wp-block-heading">How does using open source benefit telcos specifically?</h2> <p>Open source architectures serve as engines for accelerated innovation, thanks to global developer ecosystems that collaboratively debug, optimize, and expand software capabilities. Upstream alignment removes proprietary forks and hidden dependencies, giving organizations the flexibility to inspect, modify, and integrate code dynamically.</p> <p>This is particularly relevant for telcos, which have been historically burdened by rigid, vertically integrated legacy systems and vendor lock-in. In addition, telco networks span highly diverse hardware environments, ranging from centralized core data centers to resource-constrained far-edge cell towers and open RAN distributed units (DUs). As a result, telcos typically face massive capital and operational costs when scaling or updating networks. Moreover, telcos have to navigate a matrix of global and regional regulations, including those around security and data sovereignty. In such complex deployments, even minor software updates or compliance adjustments introduce significant operational overhead.</p> <p>Open source software allows operators to more easily swap underlying infrastructure blocks, as it provides modular blueprints which enable a composable platform architecture.  Likewise, through open source software, prototyping next-generation features is faster due to the global community of developers. Finally, open source software does not require specialized, expensive proprietary hardware and can be deployed directly onto general-purpose hardware which reduces total cost of ownership. These factors mean the open source model reduces time-to-market for new services, simplifies regulatory compliance across fragmented infrastructures, and shifts the industry’s focus from navigating proprietary vendor restrictions to innovating with over-the-top value-added services.</p> <h2 class="wp-block-heading">The benefits of using Canonical Kubernetes in Sylva</h2> <p>By using Canonical Kubernetes within Sylva, enterprises benefit from Canonical’s focus on upstream consistency, long lifecycle maintenance, and decoupled architecture. Canonical Kubernetes provides a trusted out of the box approach, while avoiding locking users into a restrictive stack. Instead, the platform remains completely open for downstream customization and architectural extension. This transparency ensures that the underlying infrastructure conforms cleanly to the base Ubuntu Linux layers without hiding behind custom forks or proprietary management wrappers.</p> <p>The modular architecture of <a href="https://ubuntu.com/kubernetes">Canonical Kubernetes</a> allows systems to seamlessly align with Sylva’s default cloud-native units. Standard <a href="https://sylva-projects.gitlab.io/docs/1.5/configuration/units-list/">Sylva software units</a> deploy onto Canonical Kubernetes out of the box, without requiring custom application wrappers, keeping the GitOps pipeline clean and predictable. In addition, Canonical Kubernetes natively supports enhanced platform awareness (EPA) features like SR-IOV, DPDK, and PTP synchronization required for 5G without needing proprietary operators. This decoupled, modular architecture allows operators to scale efficiently from raw hardware to complex 5G application workflows. </p> <p>Because telco environments often demand unique customizations, Canonical directly supports customers through this integration process, as demonstrated by its contributions within Sylva. For telcos requiring custom component tailoring or specific upstream modifications, Canonical can extend this support through its large open source software catalog of containers. This ensures that customized telco containers are built, validated, and maintained with the same strict trusted, regulatory and operational principles as the core distribution itself.</p> <p>The principles of improved operational predictability and reduced risk also apply beyond initial integration. Telcos need platforms that can be adapted to their network requirements, then operated safely for many years. Their clouds are built to match long physical infrastructure lifespans, not rapid upstream software deprecation cycles. Canonical offers up to 15 years of Long Term Support (LTS) for its Kubernetes distributions via <a href="https://ubuntu.com/pro">Ubuntu Pro</a>. This long-term stability is a particular benefit to telcos, where upgrading core networks (like 5G Core or O-RAN) carries massive operational risk. LTS Kubernetes enables operators to build once and receive maintenance for a longer operational window, without undergoing forced, disruptive platform migrations. This offers telcos a stable platform foundation that frees engineering teams from recurring upgrade cycles, allowing them to focus on upper-layer network application performance.</p> <h2 class="wp-block-heading">Declarative cluster lifecycle management with Canonical Kubernetes</h2> <p>While the telco ecosystem agrees on the necessity of cloud-native standardization, the way Kubernetes platforms are packaged and operated can either reinforce or weaken Sylva’s open model. Approaches that rely on highly integrated, specialized platform stacks or heavily modified Kubernetes distributions may end up tying cluster functionality to proprietary management utilities and tightly coupled operating system dependencies. While this may offer a high degree of curation out of the box, the underlying infrastructure becomes highly opinionated, introducing an architectural paradox for telcos seeking greater vendor neutrality. Over time, this subtly introduces a new form of platform-specific lock-in, restricting an operator’s ability to swap out software components or straightforwardly migrate workloads to alternate infrastructures. </p> <p>Canonical offers a different approach.  By aligning with Sylva’s open infrastructure standards, Canonical Kubernetes allows Sylva’s declarative model to operate without an additional proprietary control layer. </p> <p>Within a Sylva-managed telco cloud, Cluster API (CAPI) and FluxCD provide the declarative lifecycle and GitOps control framework used to orchestrate management and workload clusters. Cluster definitions, infrastructure provider selections, and platform configuration are maintained declaratively in Git through the sylva-units deployment model, which generates FluxCD Kustomizations and HelmReleases to orchestrate platform components and dependencies. FluxCD continuously reconciles the desired state from Git into the management cluster, where Cluster API controllers interpret the resulting custom resources and coordinate cluster provisioning, scaling, upgrades, and remediation workflows.</p> <p>To execute these declarative specifications natively without the abstraction layers that typically drive vendor lock-in, CAPI coordinates the deployment across multiple provider layers. Sylva integrates CAPI providers (such as the CAPI bootstrap provider for Canonical Kubernetes and the Canonical Kubernetes control plane provider) to translate high-level CAPI specifications into Canonical Kubernetes node and control-plane configurations. These providers automate node bootstrap, control-plane initialization, and cluster joining using Canonical Kubernetes installation and configuration mechanisms, including snap-based package delivery where applicable. Once operational, Canonical Kubernetes clusters remain under continuous reconciliation through FluxCD and Cluster API control loops, enabling declarative upgrades, configuration drift correction, and infrastructure remediation workflows.</p> <h2 class="wp-block-heading">Conclusion</h2> <p>Project Sylva standardizes how telco clouds are built using open, non-fragmented declarative blueprints. The integration of Canonical Kubernetes demonstrates that open standards can be maintained without adding heavy, opinionated software bundles. </p> <p>However, in an industry where upgrading a core network runtime carries significant operational and compliance risks, frequent forced updates present a major vulnerability. Canonical delivers a clean separation of concerns, while supporting the footprint with long-term maintenance through Ubuntu Pro. Further, through custom integration support and thanks to our extensive LTS open source software catalog, Canonical ensures that telcos can customize, validate, and maintain their specific runtime components within a trusted framework over these extended lifecycles. With Canonical, telcos can deploy for Day 1, operate for the long run, and keep their network future open.</p> <h2 class="wp-block-heading">Next steps</h2> <p>Learn how Canonical solutions provide a stable, validated, and open foundation for telco workloads.</p> <ul> <li><a href="https://canonical.com/solutions/telco">Learn about Canonical’s solutions for telco</a></li> <li><a href="https://ubuntu.com/engage/kubernetes-for-telco-performance">Unlock the full potential of Kubernetes for telco performance</a></li> <li><a href="https://canonical.com/solutions/telco/5g-core">Transform your 5G infrastructure with Canonical</a></li> </ul> <p><a href="https://canonical.com/solutions/telco#get-in-touch">Get in touch with Canonical’s telco team</a></p> estelacarmona (estelacarmona)canonical kubernetesSylvaTelcoTelco 5Gtelco edge cloudThu, 11 Jun 2026 10:34:37 +0000https://ubuntu.com//blog/what-is-rdma-over-converged-ethernet-roce<p>Previous articles walked through RDMA (Remote Direct Memory Access) as a programming model and InfiniBand as the fabric that was built around it. Both led to the same conclusion, even if it was never stated outright: moving data, not compute, becomes the bottleneck once systems scale. So what happens when you want RDMA, but you’re [&hellip;]</p> <p>Previous articles walked through <a href="https://ubuntu.com/blog/what-is-rdma">RDMA (Remote Direct Memory Access)</a> as a programming model and InfiniBand as the fabric that was built around it. Both led to the same conclusion, even if it was never stated outright: moving data, not compute, becomes the bottleneck once systems scale.</p> <p>So what happens when you want RDMA, but you’re already running an Ethernet network you’re not keen to replace? That’s usually where RDMA over Converged Ethernet (RoCE) enters the conversation.</p> <p>At first, it sounds straightforward. Keep the RDMA semantics, keep the verbs model (the low-level RDMA API used to post send/receive and memory operations), just run it over Ethernet. In reality, it works a bit like fitting a racing engine into a standard road car. You can do it, but the rest of the system has to be able to keep up. In this article, we’ll explore what RoCE is, how it works, and when to use it.</p> <h1 class="wp-block-heading">What is RoCE?</h1> <p>RDMA over Converged Ethernet (RoCE) runs the RDMA programming model over standard Ethernet networks. Applications use the same verbs interface to read and write directly to remote memory, bypassing the kernel and minimizing CPU involvement. The change is in the transport: instead of a purpose-built InfiniBand fabric, RDMA operations are carried over Ethernet.</p> <p>RoCE exists in two variants. RoCEv1 operates within a single Layer 2 broadcast domain. RoCEv2 encapsulates RDMA traffic in UDP/IP, which makes it routable across Layer 3 networks. In practice, deployments standardize on RoCEv2 because it fits leaf–spine designs, network segmentation, and multi-rack scale.</p> <p>While the programming model does not change, the network behavior does. Ethernet does not guarantee lossless delivery by default, so RoCE relies on additional mechanisms to control congestion and avoid drops. That design choice shifts responsibility from the application to the network. Performance and predictability now depend on how the Ethernet fabric is designed, configured, and operated.</p> <p>This is the key idea to keep in mind. RDMA is the model. RoCE is one way to implement it on top of Ethernet.</p> <h2 class="wp-block-heading">Where RoCE fits</h2> <p>RoCE is most relevant in environments where Ethernet is already the dominant networking model and introducing a separate fabric would increase operational complexity, not only because it introduces additional infrastructure, but also because it brings a different networking model, tooling, and operational expertise that teams may not already have in place. It allows RDMA to be introduced incrementally, without changing how the network is provisioned or managed at a high level.</p> <p>In practice, this shows up in distributed storage systems, database clusters, and accelerator-driven workloads that are deployed on top of standard Ethernet infrastructure. In these environments, the ability to reuse the existing network is often as important as the performance characteristics themselves. In many cases, this direction reflects a practical compromise: pushing beyond application performance limits while avoiding a full redesign of the network stack from scratch.</p> <h2 class="wp-block-heading">Ethernet versus InfiniBand behavior</h2> <p>To understand why RoCE behaves differently in practice, it helps to compare the two worlds it bridges: InfiniBand, where RDMA was designed to run, and Ethernet, where it is being adapted.</p> <p>InfiniBand enforces lossless communication as part of the fabric. Flow control and congestion management are integrated into the transport, which keeps latency stable under load.</p> <p>Ethernet follows a different model, where packet loss is expected and recovery is handled by higher layers. That choice is not accidental; it comes from how Ethernet evolved. Early Ethernet was designed as a shared medium, with many hosts contending for the same wire. Simplicity and cost mattered more than strict delivery guarantees, so the network pushed complexity up the stack. If a frame collided or a buffer overflowed, it was cheaper to drop it and let higher layers retry than to coordinate every sender and receiver in real time.</p> <p>That design scaled well as speeds increased and switching replaced hubs. The network stayed simple and fast, while protocols like TCP took on responsibility for reliability, ordering, and congestion control. It works well for web traffic, storage over IP, and most enterprise workloads, where a lost packet can be retransmitted without much consequence.</p> <p>RDMA changes that assumption. It expects the network to behave predictably and avoid drops altogether, because retransmissions break latency guarantees and disrupt fine-grained communication patterns. RoCE therefore has to retrofit loss-avoidance mechanisms onto a transport that was never designed to be strictly lossless in the first place. RoCE bridges that gap by introducing a set of mechanisms that approximate lossless behavior for RDMA traffic.</p> <p>At this point, it helps to step back and ask why these additional mechanisms are needed in the first place. Ethernet did not suddenly become problematic; the workload changed.</p> <h1 class="wp-block-heading">Why RDMA stresses Ethernet</h1> <p>The key challenge with RoCE is that RDMA expects a predictable, near-lossless transport, while Ethernet was originally designed around best-effort delivery. Most of the additional mechanisms around RoCE exist to bridge that gap.</p> <p>RDMA traffic patterns tend to be highly synchronized and bursty. Distributed training jobs and tightly coupled HPC workloads often trigger collective operations where many nodes exchange data simultaneously. This creates what operators call “incast”: multiple senders targeting the same receiver or the same set of links at once. Switch buffers fill rapidly, and in a traditional Ethernet network that would simply lead to packet drops.</p> <p>TCP tolerates that behavior because retransmission is built into the transport. RDMA does not. A single dropped packet can stall a queue pair and introduce latency spikes that ripple through the entire workload.</p> <p>Priority flow control (PFC) was introduced to avoid drops by pausing traffic before queues overflow. The problem is that the pause applies to the ingress port and priority class, not only to the congested flow itself. Unrelated traffic can therefore be blocked as well. This phenomenon, known as head-of-line blocking, is one of the reasons RoCE fabrics can become unstable under congestion.</p> <p>Load balancing creates additional pressure. Ethernet fabrics typically rely on equal-cost multipath (ECMP) hashing to spread flows across multiple paths, but synchronized AI and HPC traffic patterns do not distribute evenly. Large flows can land on the same links while other paths remain underutilized, concentrating congestion inside a subset of the fabric.</p> <p>Mechanisms such as explicit congestion notification (ECN), data center bridging (DCB), and later data center quantized congestion notification (DCQCN) were introduced to make this behavior manageable. ECN marks packets before queues overflow so endpoints can slow down gradually. DCB defines how traffic classes are isolated and prioritized across the fabric. DCQCN builds on those signals to regulate sender rates dynamically.</p> <p>RoCE performance thus depends heavily on how the Ethernet network is engineered. A well-tuned fabric can achieve latency and throughput close to InfiniBand. A poorly tuned one can become unpredictable under load. Queue thresholds, ECN marking points, PFC priorities, maximum transmission unit (MTU) values, and network interface card (NIC) parameters all interact, which is why production RoCE deployments often require careful validation and iterative tuning under realistic traffic conditions.</p> <h2 class="wp-block-heading">Can RoCE share the same fabric as IP traffic?</h2> <p>The mechanisms described above already push Ethernet close to its limits under synchronized RDMA workloads. When the same fabric also carries general IP traffic, those effects can become harder to control and easier to trigger.</p> <p>Can RoCEv2 coexistence with standard Ethernet and IP traffic be maintained without affecting performance? RDMA traffic assumes a controlled, near-lossless environment. IP traffic assumes packet loss and recovery. Bringing both together requires explicit separation within the same network, typically through traffic classes, buffer allocation, and scheduling policy.</p> <p>Some environments operate a fully converged fabric, where all traffic shares the same infrastructure. This approach reduces hardware footprint but increases sensitivity to configuration errors, as congestion in one class can affect others. Other environments introduce logical separation, using VLANs or QoS classes to isolate RDMA traffic while keeping a shared physical network. The most conservative approach is a dedicated fabric, where RDMA traffic is completely isolated from other workloads.</p> <p>Operational experience tends to favor some form of isolation. It reduces the number of variables involved when diagnosing performance issues and makes behavior easier to reason about under load.</p> <h1 class="wp-block-heading">Evolving congestion control</h1> <p>While RoCE can deliver excellent performance, large deployments also expose some of the weaker aspects of Ethernet under sustained congestion and synchronized traffic. Congestion spreads more easily, synchronized traffic patterns create hotspots, and mechanisms such as PFC can stabilize the fabric in one situation while amplifying instability in another.</p> <p>Large AI training clusters pushed these issues into the spotlight once deployments started scaling into thousands of GPUs. In her OCP Global Summit 2022 keynote, Alexis Bjorlin, then VP of Infrastructure at Meta, explained that communication overhead and tail latency were directly affecting training efficiency: around 30% of AI training time was spent in networking and, for some benchmark models, more than 50%. That drove investment into topology-aware collectives, routing, and congestion management. At that scale, the network becomes part of the distributed compute system rather than simple transport infrastructure.</p> <p>The industry response has focused on making Ethernet behave more predictably under large-scale RDMA traffic, while reducing dependence on mechanisms such as PFC.</p> <p>A few notable examples illustrate where things are heading:</p> <ul> <li>NVIDIA Spectrum-X keeps the RoCE model, but tightly integrates Spectrum switches, BlueField DPUs, adaptive routing, telemetry, and congestion control into a single Ethernet platform optimized for AI clusters.</li> <li>The Ultra Ethernet Consortium (UEC), formed in 2023 under the Linux Foundation, takes a more open approach. Its specifications focus on stronger congestion signaling, multipathing, packet spraying, and transports that tolerate out-of-order delivery.</li> <li>Google’s Falcon transport, opened through OCP in 2023, moves even further away from traditional RoCE designs. It introduces hardware-assisted retransmission, programmable congestion control, and multipath transport semantics intended to work efficiently on lossy Ethernet fabrics.</li> <li>Broadcom’s Scale-Up Ethernet (SUE) framework focuses on tightly coupled accelerator domains using mechanisms such as credit-based flow control, topology-aware routing, and in-network collectives. Recent products such as Tomahawk Ultra and Thor Ultra align closely with the broader UEC direction.</li> </ul> <p>RoCE exposed how difficult it is to make traditional Ethernet behave predictably under synchronized RDMA traffic at large scale. These newer approaches are all attempts to reduce that sensitivity, either by tightening integration around RoCE itself or by moving toward new Ethernet transport models designed specifically for AI and HPC communication patterns.</p> <h1 class="wp-block-heading">The Canonical perspective</h1> <p>RoCE depends on alignment across the entire software and hardware stack. Kernel drivers, user space libraries, NIC firmware, and the way workloads are attached to the network all contribute to the final behavior.</p> <p>On Ubuntu, that alignment starts with upstream RDMA plumbing that operators already recognize. The <a href="https://launchpad.net/ubuntu/+source/rdma-core">rdma-core</a> stack provides libibverbs and its providers, which expose a consistent RDMA programming interface regardless of whether the underlying transport is InfiniBand or RoCE. It also includes connection management and tooling such as <a href="https://manpages.ubuntu.com/manpages/resolute/man1/ibv_devinfo.1.html">ibv_devinfo</a> and <a href="https://manpages.ubuntu.com/manpages/resolute/man1/rping.1.html">rping</a>. In the kernel, the mlx5 driver family (for NVIDIA/Mellanox ConnectX), irdma (Intel E810/Columbiaville), bnxt_re (Broadcom NetXtreme-E), and ice/ixgbe (Intel NICs) backends expose RoCEv2 capabilities consistently. Features such as SR-IOV, VF representors, and devlink are available out of the box, which matters when you need to reason about queues, rate limiting, or firmware settings without stepping outside the distribution.</p> <p>Day‑to‑day operations tend to rely on a small set of Linux primitives that are easy to overlook but critical for RoCE. <a href="https://manpages.ubuntu.com/manpages/resolute/man8/ethtool.8.html">ethtool</a> and <a href="https://manpages.ubuntu.com/manpages/resolute/man8/devlink-health.8.html">devlink-health</a> expose NIC capabilities and health. <a href="https://manpages.ubuntu.com/manpages/resolute/man8/tc.8.html">tc</a> with <a href="https://manpages.ubuntu.com/manpages/bionic//man8/tc-mqprio.8.html">mqprio</a> shape traffic classes. They are used to map RoCE traffic to a dedicated priority, enable PFC on that class, and tune queue bandwidth. <a href="https://manpages.ubuntu.com/manpages/resolute/man7/cgroups.7.html">cgroups</a> and CPU pinning keep data paths predictable to isolate RDMA poller threads or user-space data plane processes on specific cores and reduce scheduler jitter. All of this while standard Linux networking tools remain part of the workflow for inspecting and configuring the underlying Ethernet interfaces that carry RoCE traffic. When things misbehave, counters exposed through /sys/class/infiniband (used for both InfiniBand and RoCE devices), ethtool -S, and switch telemetry are what let you correlate queue pressure with application latency.</p> <p>Driver and firmware cohesion is where many deployments struggle. Ubuntu tracks rdma-core and kernel changes together, which reduces surprises when kernels move. Where vendor features matter, NVIDIA DOCA-OFED is available through Ubuntu packaging so platform teams can use advanced capabilities on BlueField or ConnectX without forking the base system. The same applies to Intel and Broadcom stacks, which are validated against LTS kernels rather than treated as one-off add-ons.</p> <p>This matters even more as Ethernet fabrics continue to evolve for AI and HPC workloads. Canonical works closely with silicon vendors, switch manufacturers, and ecosystem partners to follow developments around technologies such as Spectrum-X, Ultra Ethernet, Falcon, and next-generation RoCE congestion control. The goal is not simply hardware enablement. It is making sure Ubuntu and the surrounding cloud-native stack can expose those capabilities consistently through upstream kernels, drivers, orchestration tooling, and CNCF integrations as the ecosystem evolves.</p> <p>On the orchestration side, RDMA is rarely something a single process “just uses.” It has to be surfaced cleanly to containers and VMs, which is where SR-IOV VFs, device plugins, and CNI integrations come into play. Canonical keeps close to CNCF projects here, so the platform can consume what vendors and the community already provide rather than inventing a parallel stack. In practice, that means platform teams can bring in components such as NVIDIA’s Network Operator, SR-IOV-focused operators, RDMA device plugins, and Multus-based secondary networking. Ubuntu provides the predictable host layer that allows those components to work together consistently. These pieces take care of discovering devices, carving out VFs, and attaching them to workloads, while Ubuntu underneath keeps the drivers, kernel interfaces, and networking behavior consistent enough that those higher layers behave as expected.</p> <p>Bare-metal provisioning with MAAS and lifecycle management with Juju fit into the same picture. They let platform teams model NIC firmware, kernel parameters, and network configuration alongside the workload, rather than treating RDMA as a special case configured by hand. In practice, this reduces drift. And with RoCE, drift is often what turns a stable cluster into one with unpredictable tail latency.</p> <p>Observability ties it all together. RDMA issues rarely show up as hard failures; they surface as latency spread, queue buildup, or uneven throughput. Having a consistent set of kernel drivers, user-space tools, and metrics on Ubuntu makes it possible to trace those symptoms back to specific queues, links, or policies, which is what ultimately keeps a RoCE deployment usable under load.</p> <h1 class="wp-block-heading">Designing and operating RoCE in practice</h1> <p>RoCE aligns with Ethernet and integrates naturally into existing environments, which is precisely why it keeps coming up in design discussions. It allows teams to push performance further without introducing a parallel networking stack. At the same time, that flexibility comes with a shift in responsibility. The network no longer guarantees behavior by construction. It has to be engineered, observed, and continuously validated.</p> <p>Most teams follow a similar path, even if they describe it differently. They start by validating whether RDMA is actually the right tool for their workload. Not every distributed system benefits from it, and some behave better with simpler transport models. From there, the focus moves quickly to the network: topology consistency, traffic isolation, buffer tuning, and congestion control are not optional details. They are part of the application design.</p> <p>This is also where many projects stall. RoCE works well in controlled environments, then becomes unpredictable when scaled or mixed with other traffic. That gap is rarely about hardware capability. It is about how the system is put together and how much visibility teams have into its behavior.</p> <p>This is the point where it usually makes sense to step back and look at the full stack rather than individual components. The NIC, the kernel, the switch configuration, and the orchestration layer all interact. Treating them separately often leads to local optimizations and global instability. Treating them as a system tends to produce more consistent results.</p> <p>From a practical standpoint, the next step is not to choose between RoCE and something else in isolation. It is to validate the workload, test the network behavior under realistic conditions, and understand where variability comes from. That work tends to surface quickly whether the existing Ethernet fabric can support the requirements or whether a more controlled approach is needed.</p> <p>The right approach depends on context. Some deployments converge successfully on RoCE with careful design. Others decide that a more tightly controlled fabric is the better option. What matters is having the data and the operational understanding to make that decision with confidence.</p> <p>If you are exploring RDMA over Ethernet today, this is exactly the kind of problem Canonical works on with customers and partners. From enabling RDMA stacks on Ubuntu, to validating performance across different NICs and switches, to integrating those capabilities into production platforms, the focus is on making these systems behave predictably under real workloads rather than synthetic benchmarks.</p> <p>If you are evaluating RoCE, next-generation Ethernet fabrics, or AI/HPC networking architectures on Ubuntu, <a href="https://canonical.com/solutions/telco#get-in-touch">get in touch with Canonical</a> to discuss your requirements and deployment goals.</p> Benjamin Ryzman (Benjamin Ryzman)AIAI FactoryData center networkingHPCinferencenetworkTue, 09 Jun 2026 15:05:05 +0000https://ubuntu.com//blog/beyond-tokens-per-watt<p>Tokens per watt (TpW) – the measure of useful AI work produced per watt of energy consumed – is the metric at top of mind for CEOs, heads of AI, and infrastructure teams alike. With the tremendous cost of GPU clusters, extracting as much value as possible from the expense is critical. But in the [&hellip;]</p> <p>Tokens per watt (TpW) – the measure of useful AI work produced per watt of energy consumed – is the metric at top of mind for CEOs, heads of AI, and infrastructure teams alike. With the tremendous cost of GPU clusters, extracting as much value as possible from the expense is critical.</p> <p>But in the pursuit of tokens, it’s important to remember that hardware efficiency isn’t the only factor influencing data center operating costs, or the output of useful, revenue-generating AI work. While TpW is crucial, we also need to consider time-to-value and the impact of human productivity, which are largely determined at the software level.</p> <p>We’re shaping Ubuntu to be the software foundation for efficient AI, and in this article, I’ll share some examples of what we mean when we say that we are optimizing Ubuntu for AI. With Ubuntu 26.04 LTS, we’re not just helping organizations get more from their hardware, we’re also making life easier and more productive for teams that rely on and support the AI stack. </p> <h2 class="wp-block-heading">An OS that’s optimized for silicon</h2> <p>How do you squeeze more tokens from your hardware? The prevailing wisdom is to prioritize model optimization, GPU utilization, time to first token, and tokens per second. However, it’s also essential to have a software layer that enables you to make the most of your silicon.</p> <p>The host operating system plays a central role in the AI infrastructure stack. That’s “central” not just in the sense that it’s important, but also in the sense that it sits in the center of the stack, acting as the bridge between the hardware and software. The OS manages the underlying compute, so it’s responsible for ensuring you can take full advantage of your GPUs and other AI accelerators.</p> <p>With that in mind, Canonical <a href="https://canonical.com/partners/silicon">partners with silicon vendors</a> (such as NVIDIA, AMD, Intel, Arm, and Qualcomm, as well as RISC-V platforms) to optimize Ubuntu across all major architectures. This optimization helps to ensure that the maximum watts are spent on AI workloads rather than OS overhead. </p> <p>We also work with partners to <a href="https://ubuntu.com/certified">certify hardware</a>. By providing standardized, pre-integrated secure boot enablement and firmware delivery, Canonical enables organizations to avoid having to do custom OS engineering for every new piece of hardware they add to their stack. Enterprises can get to value faster, and save on engineering resources.</p> <h2 class="wp-block-heading">Single command toolkit integrations</h2> <p>Let’s continue on that theme of accelerating time-to-value and enhancing human productivity. Even in the age of AI, Ubuntu remains a Linux for human beings, and a core pillar of our philosophy is minimizing the friction involved in deploying and operating AI infrastructure for our users.</p> <p>To that end, we’re collaborating with NVIDIA and AMD to integrate and distribute key AI solutions with Ubuntu. Starting with Ubuntu 26.04 LTS, users can get <a href="https://canonical.com/blog/canonical-announces-it-will-support-and-distribute-nvidia-cuda-in-ubuntu">NVIDIA CUDA</a>, <a href="https://canonical.com/blog/canonical-amd-rocm-ai-ml-hpc-libraries">AMD ROCm</a>, and <a href="https://canonical.com/blog/canonical-announces-it-will-distribute-nvidia-doca-ofed-in-ubuntu">NVIDIA DOCA-OFED</a> each with a single command. </p> <h3 class="wp-block-heading">GPGPU frameworks</h3> <p>NVIDIA CUDA and AMD ROCm are frameworks for general-purpose computing on graphics processing units (GPGPU). They are the critical software layers that enable developers to harness the massive throughput of NVIDIA and AMD GPUs for AI workloads.</p> <p>Historically, installing these frameworks required multi-step processes, and navigating dependency and compatibility issues could often prove challenging, especially for inexperienced users. But with Ubuntu 26.04 LTS, NVIDIA CUDA or AMD ROCm can each be installed with just one <strong>apt install </strong>command. </p> <p>The new distribution model can save teams hours or even days on GPGPU framework setup, so organizations can start gaining value from GPUs faster. Canonical also ensures that users have smooth upgrade paths, so they can be confident when updating, and get the benefits of the latest features of these platforms.</p> <p>Have questions about AMD ROCm on Ubuntu? <a href="https://ubuntu.com/blog/amd-rocm-on-ubuntu">We’ve just published a deep dive.</a></p> <h3 class="wp-block-heading">High-performance networking</h3> <p>For organizations with large-scale <a href="https://canonical.com/knowledge/data-and-ai-ml/what-is-an-ai-factory">AI factories</a> and HPC clusters, NVIDIA DOCA-OFED is among the go-to high-performance networking stacks. However, traditionally, the tradeoff for enabling ultra-low latency and high-throughput data transfers was the complexity of setup and maintenance. System administrators had to manage networking drivers through external installers or complex manual builds, potentially leading to version conflicts or kernel mismatch issues during OS updates.</p> <p>Now that NVIDIA DOCA-OFED can be installed seamlessly, the entire lifecycle management is simplified. Alongside rapid installation, the new workflow solves common operational pain points like kernel drift, driver incompatibility, and CI breakage following kernel or OS upgrades. Infrastructure teams can deliver speed and stability, while saving resources.</p> <h2 class="wp-block-heading">Optimized for hardware and humans</h2> <p>Jon Seager, Canonical’s VP of Engineering, has written recently about <a href="https://discourse.ubuntu.com/t/the-future-of-ai-in-ubuntu/81130">the future of AI in Ubuntu</a>. He signs off by stating that “Ubuntu is not becoming an AI product.” But what we are committed to is making Ubuntu an <em>enabler</em> for AI. Whether it’s at the silicon level with deep optimization for every architecture, or at the user level with streamlined toolkit adoption and lifecycle management, Ubuntu is the software layer that underpins an effective AI infrastructure strategy. It can help you get more tokens per watt, and beyond that, it can help you get to value faster and help bring down the operating costs for your stack.</p> <p>If you’d like to learn more about AI infrastructure best practices, and how Ubuntu can fit into your AI strategy, <a href="https://ubuntu.com/engage/open-source-ai-infrastructure">read the enterprise guide to private AI infrastructure</a>.</p> Freyja Cooper (Freyja Cooper)AI/MLAI/ML InfrastructureFri, 05 Jun 2026 10:44:14 +0000https://ubuntu.com//blog/ubuntu-core-26-ai-renesas<p>Welcome to this blog series which explores innovative uses of Ubuntu Core. Throughout this series, Canonical’s Engineers will show what you can build with our releases, highlighting the features and tools available to you. In this blog, Asa Mirzaieva, engineer from the Silicon Alliances team, will show you how to deploy optimised AI models on [&hellip;]</p> <p>Welcome to this blog series which explores innovative uses of Ubuntu Core. Throughout this series, Canonical’s Engineers will show what you can build with our releases, highlighting the features and tools available to you.</p> <p>In this blog, Asa Mirzaieva, engineer from the Silicon Alliances team, will show you how to deploy optimised AI models on Renesas RZ/V series hardware using the Dynamically Reconfigurable Processor for AI (DRP-AI). </p> <p>Deploying AI models for edge inference on specialized MPUs is particularly useful for developers looking to balance high performance with extremely low power consumption. Coupled with Ubuntu Core’s architecture, developers have an end-to-end infrastructure for managing a secure, modular deployment.</p> <p>By the end of this blog, you’ll know how to package, load, and run AI inference models on Renesas DRP-AI using snaps.</p> <h2 class="wp-block-heading"><strong>AI inference on Renesas DRP-AI</strong></h2> <p>If you aren’t familiar with <a href="https://www.renesas.com/en/design-resources/boards-kits/rz-v2h-evk">Renesas’ RZ/V</a> series, the main takeaway is that these microprocessors feature a dedicated AI accelerator called DRP-AI. This dynamically reconfigurable processor accelerates the heavy lifting of neural network inference, such as feature extraction and classification, while maintaining exceptional power efficiency. To fully understand how this acceleration is achieved, we must look at how DRP-AI dynamically reconfigures its internal dataflow to match the network architecture, contrasting sharply with traditional sequential CPU processing.</p> <figure class="wp-block-image size-full"><img alt="" height="282" loading="lazy" sizes="(min-width: 962px) 962px, 100vw" src="https://res.cloudinary.com/canonical/image/fetch/f_auto,q_auto,fl_sanitize,c_fill,w_962/https%3A%2F%2Fubuntu.com%2Fwp-content%2Fuploads%2F5937%2Fimage.png" srcset="https://res.cloudinary.com/canonical/image/fetch/f_auto,q_auto,fl_sanitize,c_fill,w_460/https%3A%2F%2Fubuntu.com%2Fwp-content%2Fuploads%2F5937%2Fimage.png 460w, https://res.cloudinary.com/canonical/image/fetch/f_auto,q_auto,fl_sanitize,c_fill,w_620/https%3A%2F%2Fubuntu.com%2Fwp-content%2Fuploads%2F5937%2Fimage.png 620w, https://res.cloudinary.com/canonical/image/fetch/f_auto,q_auto,fl_sanitize,c_fill,w_1036/https%3A%2F%2Fubuntu.com%2Fwp-content%2Fuploads%2F5937%2Fimage.png 1036w, https://res.cloudinary.com/canonical/image/fetch/f_auto,q_auto,fl_sanitize,c_fill,w_1681/https%3A%2F%2Fubuntu.com%2Fwp-content%2Fuploads%2F5937%2Fimage.png 1681w, https://res.cloudinary.com/canonical/image/fetch/f_auto,q_auto,fl_sanitize,c_fill,w_1920/https%3A%2F%2Fubuntu.com%2Fwp-content%2Fuploads%2F5937%2Fimage.png 1920w, https://res.cloudinary.com/canonical/image/fetch/f_auto,q_auto,fl_sanitize,c_fill,w_962/https%3A%2F%2Fubuntu.com%2Fwp-content%2Fuploads%2F5937%2Fimage.png 962w" width="962"/></figure> <h2 class="wp-block-heading"><strong>Packaging and Deploying Edge AI with Ubuntu Core</strong></h2> <p>In a nutshell, running AI workloads at the edge involves preparing the model, integrating it with the runtime and application, and ensuring it can be reliably deployed on target devices, as seen on the diagram below.</p> <p>The diagram shows this workflow for Renesas RZ/V platforms: development and packaging are done on a host system (such as your laptop or build server running Ubuntu), while deployment targets the RZ/V device running Ubuntu Core.</p> <p>On this host system, models are compiled with the DRP-AI toolchain and packaged together with the runtime and the application into a snap; this snap is then deployed to the target device as a complete AI solution</p> <figure class="wp-block-image size-full"><img alt="" height="863" loading="lazy" sizes="(min-width: 1600px) 1600px, 100vw" src="https://res.cloudinary.com/canonical/image/fetch/f_webp,q_auto,fl_sanitize,c_fill,w_1600/https%3A%2F%2Fubuntu.com%2Fwp-content%2Fuploads%2F985f%2Frenesas.webp" srcset="https://res.cloudinary.com/canonical/image/fetch/f_webp,q_auto,fl_sanitize,c_fill,w_460/https%3A%2F%2Fubuntu.com%2Fwp-content%2Fuploads%2F985f%2Frenesas.webp 460w, https://res.cloudinary.com/canonical/image/fetch/f_webp,q_auto,fl_sanitize,c_fill,w_620/https%3A%2F%2Fubuntu.com%2Fwp-content%2Fuploads%2F985f%2Frenesas.webp 620w, https://res.cloudinary.com/canonical/image/fetch/f_webp,q_auto,fl_sanitize,c_fill,w_1036/https%3A%2F%2Fubuntu.com%2Fwp-content%2Fuploads%2F985f%2Frenesas.webp 1036w, https://res.cloudinary.com/canonical/image/fetch/f_webp,q_auto,fl_sanitize,c_fill,w_1681/https%3A%2F%2Fubuntu.com%2Fwp-content%2Fuploads%2F985f%2Frenesas.webp 1681w, https://res.cloudinary.com/canonical/image/fetch/f_webp,q_auto,fl_sanitize,c_fill,w_1920/https%3A%2F%2Fubuntu.com%2Fwp-content%2Fuploads%2F985f%2Frenesas.webp 1920w, https://res.cloudinary.com/canonical/image/fetch/f_webp,q_auto,fl_sanitize,c_fill,w_1600/https%3A%2F%2Fubuntu.com%2Fwp-content%2Fuploads%2F985f%2Frenesas.webp 1600w" width="1600"/></figure> <p>The following sections walk through each step in detail: from model compilation with DRP-AI TVM to packaging and running inference on the device.</p> <h3 class="wp-block-heading"><strong>Compiling with DRP-AI TVM</strong></h3> <p>Just like other advanced AI pipelines, DRP-AI TVM requires you to compile your model (such as ONNX) to generate Runtime Model Data. The stack leverages the EdgeCortix MERA Compiler Framework to map your AI model into a highly efficient instruction set that the CPU and DRP-AI hardware can process collaboratively.</p> <p>Because model compilation relies on specific SDKs and the EdgeCortix MERA Compiler Framework, this step is typically performed on a dedicated host machine (or Docker container) and is not handled by our runtime snap.</p> <p>For step-by-step instructions on how to set up your environment and compile your ONNX models, please refer to the official <a href="https://github.com/renesas-rz/rzv_drp-ai_tvm/tree/main/tutorials">DRP-AI TVM Compiling Tutorials</a> provided by Renesas.</p> <p>Once your model has been pruned, optimized, and compiled on your host environment, the next step is getting both the runtime binaries and the compiled model onto your board.</p> <h3 class="wp-block-heading"><strong>Packaging your AI application in a snap</strong></h3> <p>To run inference securely and reliably, we package the applications into a snap. Canonical has created an example repository, <a href="https://github.com/canonical/rzv_drp-ai_tvm_snap/">rzv_drp-ai_tvm_snap</a>, which bundles the upstream Renesas example applications so they can be easily installed and managed via snapd.</p> <p>In the snap, we package three major components:</p> <ul> <li>The DRP-AI TVM runtime library (libdrp_tvm_rt.so and its dependencies)</li> <li>The compiled tutorial application (tutorial_app_v2ml)</li> <li>The pre-compiled AI model data (located in the project’s models/ directory)</li> </ul> <p>Thanks to Snapcraft’s advanced tooling, you can cross-compile the entire application for arm64 right from an amd64 host.</p> <p>Once built, you can transfer your resulting snap to your RZ/V2L board and install it. Currently, accessing hardware interfaces relies on devmode confinement:</p> <pre class="wp-block-code"><code>sudo snap install --devmode rzv-drp-ai-tvm-examples_*.snap</code></pre> <h3 class="wp-block-heading"><strong>Under the Hood: The snapcraft.yaml File</strong></h3> <p>The magic behind this secure, cross-compiled package is the snapcraft.yaml file. This single declarative file dictates how the AI application is built and packaged. Here is a simplified snippet of how it orchestrates the three major components:</p> <pre class="wp-block-code"><code>name: rzv-drp-ai-tvm-examples<br/>base: core24<br/>confinement: devmode<br/><br/>apps:<br/>  tutorial-app:<br/>    command: usr/bin/launch-tutorial.sh<br/><br/>parts:<br/>  tvm-runtime:<br/>    plugin: nil<br/>    source: [https://github.com/renesas-rz/rzv_drp-ai_tvm.git](https://github.com/renesas-rz/rzv_drp-ai_tvm.git)<br/>    override-prime: |<br/>      craftctl default<br/>      # 1. Install runtime library<br/>      cp -a $CRAFT_PART_SRC/obj/build_runtime/v2m/lib/* $CRAFT_PRIME/usr/lib/<br/>      # 2. Install the compiled model<br/>      cp -a ${CRAFT_PROJECT_DIR}/models/ $CRAFT_PRIME/usr/bin/<br/><br/>  tutorial-app:<br/>    after: [tvm-runtime]<br/>    plugin: cmake<br/>    source: ${CRAFT_PROJECT_DIR}/../parts/tvm-runtime/src/apps<br/>    override-prime: |<br/>      craftctl default<br/>      # 3. Install compiled binary<br/>      cp -a $CRAFT_PART_BUILD/tutorial_app_v2ml $CRAFT_PRIME/usr/bin/<br/></code></pre> <p>This configuration maps directly to the major components we discussed:</p> <ul> <li><strong>Component 1: The Runtime Library:</strong> Handled by the tvm-runtime part. It fetches the upstream Renesas DRP-AI TVM source code and copies the pre-built TVM runtime libraries into the snap’s runtime path.</li> <li><strong>Component 2: The Compiled Model:</strong> Also handled in the tvm-runtime part. The locally prepared AI model data is pulled directly from the project’s models/ folder into the snap so it’s readily available at runtime.</li> <li><strong>Component 3: The Tutorial Application:</strong> Handled by the tutorial-app part. It uses the cmake plugin to cross-compile the C++ tutorial application specifically for the arm64 architecture, placing the final tutorial_app_v2ml binary into the snap.</li> </ul> <h3 class="wp-block-heading"><strong>Installing the snap</strong></h3> <p>Run the following command after the successful build of the snap (XXX stands for the version).</p> <p>devmode is required to access the DRP-AI devices from within the snap.</p> <pre class="wp-block-code"><code>sudo snap install rzv-drp-ai-tvm-examplesXXX.snap --devmode</code></pre> <h3 class="wp-block-heading"><strong>Running the Inference Examples</strong></h3> <p>After the snap is installed, running the pre-packaged application is as simple as calling the snap command.</p> <p>To run the ResNet18/ResNet50 image-classification inference (assuming you’ve provided the compiled model data and input files to the board):</p> <pre class="wp-block-code"><code>rzv-drp-ai-tvm-examples.tutorial-app<br/></code></pre> <p>Make sure to use 640×480 bmp images with the default ONNX model.</p> <p>That’s it! You can completely separate your AI models from your application logic and firmware, providing a modular approach to updates. When you improve your model, Ubuntu Core and the Snap Store will help you deliver these updates reliably and securely over the air.</p> <p>Thanks to Ubuntu Core, you can just focus on your development and not worry about the infrastructure on how to update devices in the field or maintain system security.</p> <h2 class="wp-block-heading"><strong>What’s next?</strong></h2> <p>The Renesas DRP-AI accelerator offers a tremendous advantage for edge AI devices, delivering high-speed inference without severe power penalties. Their value for deploying embedded AI devices is indisputable.</p> <p>Now is your turn. Why don’t you try packaging your optimized DRP-AI models using snaps? Through this, you will see the benefits for yourself of the infrastructure to manage and deploy software at the edge. With Ubuntu Core, you can build your production image with your targeted snaps and hardware. This will empower you to easily flash devices in production lines. Plus, in your image, you can define what user experience you want to bring, keeping your model and intellectual property secure in its sandbox.</p> <ul> <li><a href="https://documentation.ubuntu.com/inference-snaps/">Getting started with inference snaps</a></li> </ul> Gabriel Aguiar Noury (Gabriel Aguiar Noury)AIIoTUbuntu CoreThu, 04 Jun 2026 12:36:11 +0000https://ubuntu.com//blog/risc-v-profiles-why-is-rva23-significant<p>Introduction One of the important offerings of the RISC-V Instruction Set Architecture (ISA) is the ability to customize and extend the base instruction set. An initial reaction to hearing this is often to worry about software portability and compatibility, since if every RISC-V CPU&nbsp; offers a slightly different set of instructions, software won’t be portable.&nbsp; [&hellip;]</p> <h2 class="wp-block-heading">Introduction</h2> <p>One of the important offerings of the RISC-V Instruction Set Architecture (ISA) is the ability to customize and extend the base instruction set. An initial reaction to hearing this is often to worry about software portability and compatibility, since if every RISC-V CPU  offers a slightly different set of instructions, software won’t be portable. </p> <p>This risk is that customization becomes fragmentation, which is why RISC-V offers sets of standardized extensions to help with software compatibility and portability. These are indicated with a letter or string, such as ‘F’ for floating point, or ‘V’ for vectors. There is also a number to indicate whether the device is 32-bit or 64-bit. So a CPU might be “RV64IMAC”, which means a 64-bit CPU where Integer (I), Multiply (M), Atomics (A) and Compressed (C) extensions are supported.</p> <p>To execute correctly, software has to be compiled to match the hardware, or a subset of it (as an example, for code compiled as RV64IMA, it doesn’t matter whether the hardware supports the ‘C’ extension or not, but it must support at least RV64IMA). For binary portability (the ability to run compiled binaries on different hardware) to scale, there are two options. The first is that all software would have to be written with a minimal set of extensions, which is undesirable as it would limit performance and code size. To avoid these limitations, the second option is for the ecosystem to agree on common groups of extensions that all software can target. RISC-V International calls these “profiles”.</p> <p>RISC-V first introduced profiles with RVI20 and RVA20, and since then RVA22 and RVA23 have also been ratified. This blog will examine the RVA23 profile, including its features, and explain why these features are important for Ubuntu. We’ll also go over how they support the scaling of the RISC-V ecosystem. A future blog will discuss how custom instructions can be supported in Ubuntu.</p> <h2 class="wp-block-heading">What is a profile?</h2> <p>As explained above, a profile is a set of ratified extensions.  An extension is given an identifying code, from a single letter (we saw I, M, A, and C earlier) to a string such as “zicsr”. These are concatenated together to form a description of the implementation. However this can become unwieldy, making profiles become a simpler way to describe a more complex feature set. For example, RVA23 expanded would be something like: </p> <p>rv64gc_zicsr_zicntr_zihpm_zicbom_zicbop_zicboz_zicond_zimop_zcmop_zfh_zfa_zawrs_zbc_zvfh_<br/>zvfhmin_zvbc_zvkg_zvkned_zvknha_zvknhb_zvksed_zvksh_zvkn_zvknc_zvknf_zvkng_zvks_zvksc_zvksf_<br/>zvksg_zvl128b_zihintpause_zihintntl_svpbmt_svinval_svade_sstc_sscofpmf_ssccptr_sscounterenw_<br/>shvstvecd_shvswatpa_shgatpa_shcounterenw_shvsvinval_shvstvala_shvsvpbmt_shvsvade</p> <p>Which is a bit of a mouthful to keep repeating! A profile solves the above problem as it sets a standard for what needs to be included in a CPU implementation . The above wouldn’t need repeating: all of those extensions would be included by default whenever you see “RVA23”.</p> <p><a href="https://riscv.atlassian.net/wiki/spaces/WPMU/pages/462258208/RISC-V+Profiles+Development+Process">Profiles</a> are defined by the RISC-V Profiles Task group where experts from across the industry agree on what features make sense to include by considering the target application space for that profile. </p> <h2 class="wp-block-heading">The importance of profiles for ecosystem growth</h2> <p>For RISC-V to thrive and grow, it needs a strong software ecosystem. While developers and enthusiasts might be willing to compile code from scratch for every different CPU, this quickly becomes limiting for larger organizations. Profiles create a target that both software and hardware developers can agree on, guaranteeing portability of software compiled to target RVA23 across different implementations. So an RVA23 compatible binary should be able to run on any RVA23 CPU.</p> <h2 class="wp-block-heading">Limitations of Profiles</h2> <p>While Profiles guarantee a level of binary compatibility, there are aspects of system behaviour that they don’t cover. These include initial boot, device discovery and peripheral drivers. While the code for these will still all be RVA23 compliant, it may not be portable between different implementations. RISC-V International technical working groups are also acutely aware of this, and working on specifications such as the <a href="https://github.com/riscv-non-isa/riscv-server-platform">Server Platform Specification</a> to address items such as interrupt controllers and secure boot, which are outside of the ISA profile specification. For end users developing applications, this is less likely to be a concern, but it does matter to operating system developers or those working on bare metal.</p> <h2 class="wp-block-heading">Key features for modern Linux</h2> <p>RVA23 introduced two key features that were missing from earlier profiles:</p> <ol> <li>Hypervisor</li> <li>Vectors</li> </ol> <p>While it was possible for earlier RISC-V implementations to include these as extensions, they were not mandated, so software couldn’t rely on them to be included by default. By moving them into the profile specification for RVA23, software can be optimized to make use of these features. Now let’s look at the benefits of each feature in more detail:</p> <h3 class="wp-block-heading">Hypervisors</h3> <p>Hypervisors are widely used in many applications. They provide a way for a single physical CPU to emulate multiple virtual machines (VMs) while providing isolation between them. Many end applications don’t need a whole physical CPU to themselves, so this allows for more efficient use of physical CPUs while also providing security between the separate VMs. In a datacentre where a physical CPU might have tens of processor cores, hypervisors are essential to allow efficient scaling.</p> <p>Even in small scale clusters of machines, hypervisors and VMs can be used to provide functionality such as machine migration, snapshots and isolation.. Several Canonical products make use of the hypervisor, and we see mature support for virtualization as a requirement for RISC-V to scale to applications beyond embedded devices.</p> <h3 class="wp-block-heading">Vectors</h3> <p>While hypervisors are important for scaling to large workloads, vector instructions are about accelerating individual workloads, especially those that are math-intensive. Adding vectors to a CPU incurs a significant amount of additional silicon area, but for workloads that make use of them, this also provides a large performance improvement.</p> <p>While vectors are typically associated with heavy math tasks like machine learning and image processing, even the operating system itself uses them for basic chores like copying memory. And for vectors to be available to user space, the kernel still has to be aware of the register file and associated state to manage context switches, so support is needed at the operating system level.</p> <p>RISC-V made a conscious design choice for the vector extensions to be scalable. This means that implementations can choose an appropriate vector length and the software will run without needing changes or recompilation. So a smaller in-order CPU might use 64 or 128-bit vectors in hardware, while a server class CPU could use 256 or even wider vectors without needing to recompile code. As with the hypervisor, we see vectors as essential for modern high performance processors from desktop to server.</p> <p>For smaller embedded systems, power is often a concern and even small implementations of vectors may consume significant area and power. For this reason the RVB23 profile is also being developed, which removes some of the required features from RVA23.</p> <h2 class="wp-block-heading">Why now?</h2> <p>Hardware and software are interdependent, and with any new technology they need to be co-developed. Sometimes hardware takes the “build it and they will come” approach, while in other cases it becomes apparent that the hardware is on the way, and techniques such as emulation can be used to develop the software before there is any hardware available. The latter approach also has the benefit of reducing the time to market since software is available as soon as the hardware ships.</p> <p>When we announced support for RVA23 in our Ubuntu 25.10 release, there were some questions about the lack of available silicon, but the direction of travel for the industry was obvious and we wanted to be at the forefront of it. When SpacemiT announced their K3 silicon earlier this year, <a href="https://canonical.com/blog/spacemit-announces-availability-of-ubuntu-on-k3-k1-series">we were ready to support it</a>. I’m sure we’ll see more RVA23 silicon through this year and beyond.</p> <h2 class="wp-block-heading">Conclusion</h2> <p>For the RISC-V ecosystem to scale successfully, it needs a stable base profile which is suitable for modern workloads covering use cases up to data centers and servers. The RVA23 profile provides that, and it’s why Canonical moved to requiring RVA23 from Ubuntu 25.10. The Ubuntu 26.04 release introduces Long Term Support (LTS), providing 5 years of support for any user, and up to 15 years of support through Ubuntu Pro. But for those early adopters of RISC-V, we will continue to provide Ubuntu 24.04 LTS which requires the RVA20 profile. This itself will get the same level of LTS support as any other Ubuntu LTS release. </p> <h2 class="wp-block-heading">Further reading</h2> <ul> <li><a href="https://docs.riscv.org/reference/rva23/rva23-profiles.html">RISC-V RVA23 profile specification</a></li> <li><a href="https://riscv.atlassian.net/wiki/spaces/HOME/pages/16154769/RISC-V+Technical+Specifications#RVA23-Profile">RISC-V profiles documentation</a></li> </ul> Jon Taylor (Jon Taylor)RISC-VRVA23Wed, 03 Jun 2026 16:00:21 +0000