Ubuntu 26.04 LTS brings a new Hardware Enablement stack for virtualization, delivering cutting-edge features while maintaining LTS stability.
The challenge: hardware innovation vs. LTS stability
With the advent of hardware-assisted virtualization in modern CPUs, the virtualization stack (Kernel KVM, QEMU and libvirt) is evolving quickly alongside silicon, particularly with the addition of new major hardware features such as confidential computing.
Although Ubuntu provides interim releases every six months, production environments predominantly rely on Ubuntu LTS releases, which follow a two-year cadence. In contrast, hardware innovation moves much faster, making it challenging for Ubuntu to deliver the latest virtualization features to LTS-only users in a timely manner, often causing conflicts and making backports challenging.
Introducing the HWE virtualization stack
Starting with Ubuntu 26.04 LTS, we’re bringing you the Hardware Enablement (HWE) virtualization stack: a rolling virtualization stack for the LTS that matches the latest Ubuntu release.
Note that for the very same reason, Ubuntu already offers the kernel HWE in LTS. Providing a matching HWE userspace virtualization stack alongside the HWE kernel enables users to benefit from the latest upstream developments and hardware capabilities while remaining on Ubuntu LTS.
The HWE virtualization stack updates on a predictable schedule:
-
Q1 and Q3 each year (aligned with the HWE kernel release cycle) until the next LTS
-
New upstream versions are introduced via the standard SRU (Stable Release Update) process
-
Each update happens ~3 months after Ubuntu interim releases, allowing thorough testing and real-world validation
The three-month delay is intentional – it gives us extra confidence that these updates have been tried and tested in interim releases and are less likely to introduce regressions into production systems.
At the beginning of 26.04 LTS, these two stacks are basically the same. Following the interim release 26.10, the HWE stack will fork and be upgraded to have the same upstream version as 26.10. Then, we will keep upgrading the hwe-stack at every Ubuntu release (twice a year) until after the release of the next Ubuntu LTS, 28.04 LTS. The hwe-stack on 26.04 LTS will stick to the version matching what is in 28.04 LTS for the rest of 26.04 LTS’s lifetime and continue to inherit fixes (bug fixes and security fixes) from the base in 28.04 LTS.
Ubuntu 26.04 LTS roadmap:
-
April 2026: Ubuntu 26.04 LTS base and HWE stacks released
-
October 2026: Ubuntu 26.10 released with latest versions
-
February 2027: HWE stack in 26.04 LTS upgrades to match 26.10’s versions
-
August 2028: HWE stack in 26.04 LTS upgrades to match 28.04 LTS versions and sticks with this version for the rest of 26.04 LTS.
This is the illustration of the release and upgrade of the HWE stack across future Ubuntu releases:
What’s included in the HWE stack
The HWE virtualization stack includes:
-
**qemu-hwe**: Hypervisor and system emulation
-
**libvirt-hwe**: Virtualization management library and tools
-
**edk2-hwe**: Firmware for UEFI support
-
**seabios-hwe**: BIOS firmware for compatibility
These core components are responsible for delivering virtualization features tied directly to hardware capabilities. These are quite backward compatible, so that we do not need to include the consuming applications and components like virt-manager or libvirt-python.
Variant selection
Transitioning between these two variants can be complex. Ubuntu typically manages individual packages rather than defined “virtualization stacks.” Consequently, while the package manager handles dependencies on a per-package basis, our goal is to treat the entire virtualization stack as a single, atomic unit for more consistent management.
We provide the helper script ubuntu_virt_helper via the new package ubuntu-helper-virt-hwe as a management tool of the HWE stack:
root@enticed-cichlid:~# apt install ubuntu-helper-virt-hwe
On a freshly installed system, running ubuntu_virt_helper gives the following output:
root@enticed-cichlid:~# ubuntu_virt_helper
Installed variant: none
1 packages:
ubuntu-helper-virt-hwe (1:10.2.1+ds-1ubuntu4, src:qemu-hwe)
The HWE stack is opt-in, so existing systems continue to work as-is. The base stack remains the default, and selecting HWE is an explicit action. For example, installing qemu-system-x86 pulls in the base virtualization packages:
root@enticed-cichlid:~# apt install qemu-system-x86
These are the virtualization components installed as dependencies of qemu-system-x86:
root@enticed-cichlid:~# ubuntu_virt_helper --verbose
Installed variant: base
15 packages:
ovmf (2025.11-3ubuntu7, src:edk2, auto)
ovmf-amdsev (2025.11-3ubuntu7, src:edk2, auto)
ovmf-generic (2025.11-3ubuntu7, src:edk2, auto)
ovmf-inteltdx (2025.11-3ubuntu7, src:edk2, auto)
qemu-block-extra (1:10.2.1+ds-1ubuntu3, src:qemu, auto)
qemu-system-common (1:10.2.1+ds-1ubuntu3, src:qemu, auto)
qemu-system-data (1:10.2.1+ds-1ubuntu3, src:qemu, auto)
qemu-system-gui (1:10.2.1+ds-1ubuntu3, src:qemu, auto)
qemu-system-modules-opengl (1:10.2.1+ds-1ubuntu3, src:qemu, auto)
qemu-system-modules-spice (1:10.2.1+ds-1ubuntu3, src:qemu, auto)
qemu-system-x86 (1:10.2.1+ds-1ubuntu3, src:qemu, manual)
qemu-utils (1:10.2.1+ds-1ubuntu3, src:qemu, auto)
seabios (1.17.0-1ubuntu1, src:seabios, auto)
ubuntu-helper-virt-hwe (1:10.2.1+ds-1ubuntu4, src:qemu-hwe, manual)
ubuntu-virt (1:10.2.1+ds-1ubuntu3, src:qemu, auto)
The output indicates the apt mark for each package: ubuntu-helper-virt-hwe and qemu-system-x86 are marked as manual because they were directly installed, while the other packages are marked as auto as they were pulled in as dependencies.
Since the 2 stacks are mutually exclusive and one package can be individually requested for installation, one variant can be selected by installing any package from this variant:
root@enticed-cichlid:~# apt install qemu-utils-hwe
The following packages were automatically installed and are no longer required:
adwaita-icon-theme libflac14
…
x11-common
Use ‘sudo apt autoremove’ to remove them.
Installing:
qemu-utils-hwe
Installing dependencies:
qemu-block-extra-hwe ubuntu-virt-hwe
REMOVING:
ovmf ovmf-inteltdx qemu-system-data qemu-system-modules-spice seabios
ovmf-amdsev qemu-block-extra qemu-system-gui qemu-system-x86 ubuntu-virt
ovmf-generic qemu-system-common qemu-system-modules-opengl qemu-utils
Summary:
Upgrading: 0, Installing: 3, Removing: 14, Not Upgrading: 9
Download size: 2496 kB
Freed space: 118 MB
Continue? [Y/n]
In this specific example below, installing qemu-utils-hwe does not automatically install the HWE counterparts for several related packages, as they aren’t part of qemu-utils-hwe’s dependencies. Consequently, APT issues a warning, noting that packages have been removed but have not been replaced with their respective HWE counterparts:
Get:1 http://archive.ubuntu.com/ubuntu resolute/main amd64 ubuntu-virt-hwe all 1:10.2.1+ds-1ubuntu4 [11.6 kB]
Get:2 http://archive.ubuntu.com/ubuntu resolute/main amd64 qemu-utils-hwe amd64 1:10.2.1+ds-1ubuntu4 [2389 kB]
Get:3 http://archive.ubuntu.com/ubuntu resolute/main amd64 qemu-block-extra-hwe amd64 1:10.2.1+ds-1ubuntu4 [95.4 kB]
Fetched 2496 kB in 1s (3358 kB/s)
Virt: switch of the ubuntu-virt[-hwe] stack is detected and there are orphaned removals (no counterpart being installed):
ovmf
ovmf-amdsev
ovmf-generic
ovmf-inteltdx
qemu-system-x86
qemu-system-modules-spice
qemu-system-common
qemu-system-data
qemu-system-gui
qemu-system-modules-opengl
seabios
Virt: Please install them back and use the ubuntu-virt-helper script to switch between ubuntu-virt[-hwe] packages.
(Reading database … 96412 files and directories currently installed.)
Removing ovmf (2025.11-3ubuntu7) …
Removing ovmf-amdsev (2025.11-3ubuntu7) …
Removing ovmf-generic (2025.11-3ubuntu7) …
The result can be an incomplete stack (in this case missing 11 packages when compared to before), as shown below:
root@enticed-cichlid:~# ubuntu_virt_helper --verbose
Installed variant: hwe
4 packages:
qemu-block-extra-hwe (1:10.2.1+ds-1ubuntu4, src:qemu-hwe, auto)
qemu-utils-hwe (1:10.2.1+ds-1ubuntu4, src:qemu-hwe, manual)
ubuntu-helper-virt-hwe (1:10.2.1+ds-1ubuntu4, src:qemu-hwe, manual)
ubuntu-virt-hwe (1:10.2.1+ds-1ubuntu4, src:qemu-hwe, auto)
This can break existing workflows that make use of the virtualization features. To avoid such partial exchanges, instead use the helper for a complete and safe switch. The example starts from the same conditions as above:
root@enticed-cichlid:~# ubuntu_virt_helper switch
Switching from base to hwe variant…
Installing:
ovmf-amdsev-hwe ovmf-inteltdx-hwe qemu-system-data-hwe qemu-system-modules-spice-hwe seabios-hwe
ovmf-generic-hwe qemu-block-extra-hwe qemu-system-gui-hwe qemu-system-x86-hwe ubuntu-virt-hwe
ovmf-hwe qemu-system-common-hwe qemu-system-modules-opengl-hwe qemu-utils-hwe
Suggested packages:
samba vde2 passt
REMOVING:
ovmf ovmf-generic qemu-block-extra qemu-system-data qemu-system-modules-opengl qemu-system-x86 seabios
ovmf-amdsev ovmf-inteltdx qemu-system-common qemu-system-gui qemu-system-modules-spice qemu-utils ubuntu-virt
Summary:
Upgrading: 0, Installing: 14, Removing: 14, Not Upgrading: 9
Download size: 25.5 MB
Freed space: 7168 B
Continue? [Y/n]
The helper performs a one-to-one replacement, preserving dependencies and preventing partial transitions. It also preserves each package’s auto/manual install mark, making the switch transparent to users:
root@enticed-cichlid:~# ubuntu_virt_helper --verbose
Installed variant: hwe
15 packages:
ovmf-amdsev-hwe (2025.11-3ubuntu8, src:edk2-hwe, auto)
ovmf-generic-hwe (2025.11-3ubuntu8, src:edk2-hwe, auto)
ovmf-hwe (2025.11-3ubuntu8, src:edk2-hwe, auto)
ovmf-inteltdx-hwe (2025.11-3ubuntu8, src:edk2-hwe, auto)
qemu-block-extra-hwe (1:10.2.1+ds-1ubuntu4, src:qemu-hwe, auto)
qemu-system-common-hwe (1:10.2.1+ds-1ubuntu4, src:qemu-hwe, auto)
qemu-system-data-hwe (1:10.2.1+ds-1ubuntu4, src:qemu-hwe, auto)
qemu-system-gui-hwe (1:10.2.1+ds-1ubuntu4, src:qemu-hwe, auto)
qemu-system-modules-opengl-hwe (1:10.2.1+ds-1ubuntu4, src:qemu-hwe, auto)
qemu-system-modules-spice-hwe (1:10.2.1+ds-1ubuntu4, src:qemu-hwe, auto)
qemu-system-x86-hwe (1:10.2.1+ds-1ubuntu4, src:qemu-hwe, manual)
qemu-utils-hwe (1:10.2.1+ds-1ubuntu4, src:qemu-hwe, auto)
seabios-hwe (1.17.0-1ubuntu2, src:seabios-hwe, auto)
ubuntu-helper-virt-hwe (1:10.2.1+ds-1ubuntu4, src:qemu-hwe, manual)
ubuntu-virt-hwe (1:10.2.1+ds-1ubuntu4, src:qemu-hwe, auto)
Reporting bugs and affected versions
The lifecycle of the hwe-stack is independent of the base stack because the packages of the hwe-stack are separate entities (source packages) in Launchpad. This will require extra effort e.g. when reporting a bug, to ensure the right affected package is selected and that none of the stacks miss any relevant change (including security fixes). Don’t be too concerned, but you should be aware that if you report an issue we might refine the list of affected versions. The following picture illustrates a bug report that affects qemu in both variants:
The hwe-stack in an LTS release should – where applicable – mirror the base release from which it pulls its upstream version. For example, on 28.10, if we need to SRU a change back to 26.04 LTS, we would no longer have just three SRUs. Instead, we would also need to target the two hwe-stacks in 26.04 LTS and 28.04 LTS, resulting in two additional SRUs, as illustrated in the diagram below.
Upgrade
The version scheme of the HWE components has been carefully crafted to ensure the success of both stack and release upgrades. In February 2027, at the time of the HWE stack version bump for 26.04 LTS to catch up with the upstream version of 26.10, production systems will be able to seamlessly upgrade the HWE stack of 26.04 LTS to the 26.10 release. The selected variant stays the same – although in the interim release -hwe and base will again mostly match each other.
Kernel compatibility
The HWE virtualization stack works best with the Ubuntu HWE kernel, but it’s not required. You can install the HWE virtualization stack with your existing kernel. However, to unlock the full potential of modern hardware features, pairing it with the HWE kernel is recommended.
Please try it out!
Please install Ubuntu Resolute Raccoon and start experimenting with the HWE virtualization stack by:
-
Installing any use case that needs virtualization components and
-
Switch to the HWE stack.
As of now, you might see no difference as the HWE stack is the same as the base stack, but it is important to verify that the foundations we laid out for hosting the future evolution are bullet proof. This will help in the future and ensure you will get the latest virtualization features from Ubuntu Stonking Stingray 26.10.
────────────────────────────────────────────────────────────
Questions? For technical details, please refer to the server documentation page and join the discussion on the Ubuntu community forums.