SLE 16 And The Public Cloud

On November 4th the SLE 16 family of products (SUSE Linux Enterprise Server and SUSE Linux Enterprise Server for SAP applications) was released and Public Cloud images started rolling out that day.

The major product changes such as the switch from wicked to NetworkManager and other changes are captured in the Release Notes and the Key Technical Differences documents and are the same in the Public Cloud images. That said, there are some changes in the product default setup that are different in the Public Cloud images and some other changes as compared to SLE 15 that are worth highlighting.

Networking

While in a SLE 16 self install the persistent network device naming, i.e. device names such as eth0, has disappeared as a feature and predictable names are used this is not the case in the Public Cloud images. For technical reasons we stick with persistent naming until such time when all tools that are used/needed in an instance cope well with predictable names. The name generator is supplied by the cloud-netconfig package as has been the case since the introduction of cloud-netconfig. Network setup is handled by NetworkManager instead of wicked. During migration, more on migration later, any wicked specific configuration is transformed to a NetworkManager configuration.

Security Framework

SELinux has replaced AppArmor and is in “enforcing” mode in our SLES images and in “permissive” mode in SLES For SAP applications images. This is the same behavior as in a data center from scratch installation. Speaking of SLES For SAP applications, the images now have hardening rules applied by default, meaning images with the “-hardened-” part in the image name in pint do not exist for SLES for SAP applications 16.0 and going forward. You can see the rules that are pre-applied from the security profile definition. Speaking of security settings, if you want FIPS in Azure you need to have python-azure-agent version 2.14.0.1 or higher, an update we are working on with high priority. Further you need to make changes to your subscription, or on a VM basis. Please consult the Microsoft documentation for details about FIPS enablement. Azure images will have the new version of the agent by default in the next image refresh.

Public Cloud Toolchain changes, a heads up and teaser

Speaking of updates hot on the heals of the release. The Azure CLI was not quite functional when release time for SLE 16 came around and we worked hard to get our ducks in a row in a hurry. The necessary update is available now. When running either the aws or az command line tool you will see some new behavior. You’ll see the “Launching flake” message and you might wonder what that is all about. The topic around the Public Cloud Toolchains is bigger and warrants it’s own blog that I will post in the not too distant. What I will say for now is that the commands will be a bit slower (something for us to work on) but they work as before. Using the SDKs is very different compared to SLE 15 and I need to ask you to be patient and wait for the blog that addresses the toolchains to get the details.

Root Volume Filesystem Change

The next big change is the root volume filesystem. In SLE 15 and SLE 12 the default file system for the images is XFS. While the product family (SLE) switched to btrfs as the default installed file system in SLE 15, Public Cloud images retained XFS for various technical reasons. Over time all the reasons that made us retain XFS in SLE 15 have been addressed and as such it was time to follow the product default setup of using btrfs as the root file system. Btrfs is a Copy On Write (COW) filesystem and supports filesystem internal snapshots. For btrfs features please consult the btrfs documentation. Filesystem internal snapshots help with rollbacks and also support comparison of individual files. The snapshots themselves are handled by snapper. By default snapper kicks in when the root volume is larger than 16 GB. Since our Public Cloud image root volumes are small (10 GB in AWS and GCE) it was decided to leave snapper out of the images. While Azure root volumes are larger keeping snapper out makes the behavior across all images we ship consistent. If you increase your root volume size to > 16 GB and want to take advantage of the btrfs filesystem snapshots and associated features you can simply run zypper in snapper and then configure snapper to your needs, please consult the snapper documentation. The change in filesystem has no effect on any automated process you may already have using snapshotting features provided by your cloud framework of choice.

Btrfs is not completely new to our published images. It is already the default filesystem for our SUSE Linux Micro images. SUSE Linux Micro has a transactional-update implementation which relies heavily of the btrfs snapshot feature. You will find that the subvolume layout for our SUSE Linux Micro and SLE family images is the same.

Speaking of subvolumes, the switch to btrfs may help address some of the topics that had led to a few conversations about LVM in the past. Anyway, the recommendation remains, your root volumes should remain small and any valuable data, especially your application data should be on attached volumes and not on your root volume. After all in the Public Cloud storage volumes are extremely flexible. In a non virtualized setup it is rather obvious that one does not want to buy a TB disk and then only use 10 GB of that disk for the OS and stick data onto another disk. This is where LVM comes in really handy since it also helps get around the primary partition limit. In the cloud such problems do not exist. As a note please remember that SAP does not support using btrfs as the filesystem for data storage. Meaning this change of the root volume helps with the best practice of keeping your application data on an attached storage volume that for SAP applications is then formatted with XFS.

Migration to SLE 16

Migration from SLE 15 to SLE 16 has not changed much from a user experience point of view. The process is the same as in a SLE 12 to SLE 15 migration. Install the migration related packages and then reboot. Due to the significant changes in technologies it is highly recommended to run the prechecks first to get a report about the migration. The migration process handles configuration changes, except for custom AppArmor profiles, you will have to craft appropriate SELinux configurations. A migration will not change the filesystem, so everything I stated about btrfs above only applies to instances that are started from a SLE 16 image. The migration process in a Data Center installation and the Public Cloud has been unified.

No More Modules

At the higher level of the distribution the module concept that was introduced in SLE 12 and carried forward into SLE 15 has been dropped. In SLE 16 all packages that are considered part of the distribution are delivered in 1 repository, this makes the output of “zypper lr” a lot easier to digest and it improves the registration speed significantly. Source and Debug repositories remain separated. A nice new feature for SUSE Linux Enterprise Server in SLE 16 is that access to Live-Patching is included. With this kernel live-patching is now included in SUSE Linux Enterprise Server and SUSE Linux Enterprise Server For SAP applications. Kernel Live-Patching is also coming as an included feature to SLES 15 in Q1 of 2026. We need to make some changes to the update infrastructure to support the inclusion of the repository channel in SUSE Linux Enterprise Server 15 without requiring a separate registration code. Once we have the updates to the infrastructure rolled out we will also enable automatic registration of the module in the PAYG images.

Naming Changes

Finally some non technical things to note. In SLE 16 the Service Pack naming disappears and a dot notation is used, i.e. currently we are at 16.0 and the next release next November will be 16.1. This has an effect on our Public Cloud image names in that the names will no longer be, for example, sles-15-sp7, but will be sles-16-0, no dots in image names. Also with SLE 16 we have addressed the long standing transposition for Google SLES For SAP applications image and family names. In GCE a mistake was made a long time ago and we ended up with names for our SLES for SAP applications image names where the “sap” part of the name was after the version, i.e. sles-15-sp7-sap, while everywhere else that name was correct as sles-sap-15-sp7. Over the years we kept this transposition the same for consistency. The release of SLE 16 provided us an opportunity to fix this transposition error and GCE images now follow the same names as in AWS and Azure, i.e. sles-sap-16-0, the family name follows suite.

Life-cycle Changes

And last but not least with SLE 16 the support life-cycle for any given version has changed. No more “Overlap Support” and no more “Extended Service Pack Overlap Support“. Both SLES and SLES for SAP applications have 2 years of full support. SLES for SAP applications has 3 years of Long Term Support (LTS) included for a default life-cycle of 5 years. LTS is an add on purchase for SLES. With this change in life-cycle there is a change in the pint state for images. The transition points from active to inactive to deprecated stay the same, i.e. when a given version moves into LTS the image state moves from active to inactive state in pint. 6 months prior to EOL of any given release the image moves to the deprecated state. When any given image gets replaced by a refreshed image the replaced image goes directly to the deprecated state. As previously no new workloads should be deployed from images in inactive or deprecated state. Our refresh cycle will remain the same, a 3 months rolling refresh with image refreshes for critical CVEs.

In practical terms this means when 16.1 is released the SLES 16.0 images will remain in the active state, while in SLE 15 a transition in Service Pack put the previous SLE SP images into inactive state.

In about 2 years after SLE 16.0 has been released the distribution moves into the LTS period and as such the image state transitions to inactive. The same applies to SLES for SAP applications images. Then after 4.5 years from the release of SLE 16, images move to the deprecated state. As such life-cycle management is greatly simplified as compared to SLE 15.

The change in life-cycle also has an effect on how family naming is handled in GCE. Due to the longer active support period of SLES we will not have any of the SLE 16 release series images in a generic family like we did for SLE 15, i.e. the “sles-15” family which always had the latest SLES 15 Service Pack image as the default. The generic “sles-{12|15}” family only worked because of the image transition period in SLE 12 and SLE 15. With the changes in state transition as mentioned above we have to adjust the family naming since it is not possible to have 2 active images in the same family. Well it is technically possible but will lead to surprising behavior when launching an instance from the family as whether you would get a 16.0 or 16.1 instance would depend on the release date of the image and we do not want to create such surprises. In GCE there is now a sles-16-0-$ARCHITECTURE family name and that will stay to point to the latest SLES 16.0 image. This follows the in place family naming for SLES For SAP applications. Next year when SLES 16.1 gets released there will be a new family sles-16-1-$ARCHITECTURE. This brings me to the last image name change; across the board when the architecture was left out of any name it was always implied that it was x86-64. With SLE 16 we believe we have caught all those occurrences and made the architecture explicit in any naming.

I hope this was helpful in preparation for SLE 16 and your eventual adoption of the new version of the SUSE Linux Enterprise family.