A Different Builtin Kernel For Azure On-Demand Images

The release of SUSE Linux Enterprise Server 15 is out and with it, it brings a new kernel build, kernel-azure. The new kernel is built into our on-demand images in Azure.

The -azure build of the kernel is fully supported by SUSE. For instances started from the -Standard, or -Priority images you need to contact Microsoft support first and you need to have a support agreement with Microsoft. Meaning there is no change to previous practices.

The benefit of using kernel-azure is that it will incorporate new features from Azure that need Linux kernel support faster than the kernel-default build. At each Service pack level the Azure specific changes are synced back to the kernel-default build, meaning on release day the -default and -azure kernels are pretty much the same. Over the course of a given service pack lifecycle the kernels will diverge. With this increase in feature incorporation comes the benefit of earlier access to Azure features compared to using the kernel-default. But nothing in this world is free and the price is potential kABI (Kernel Application Binary Interface) breakage, something we usually do not do within a Service Pack cycle. Because we are lifting the kABI restriction for the -azure kernel this has a few implications. The kernel-azure build has no long term support (LTSS) , i.e. it gets full support until EOL of the given service pack according to the overlap lifecycle. The potential kABI change is also the reason kernel-azure is the built in kernel in the on-demand images, rather then also being in the BYOS images. There is no support for add on products such as HA or Kernel Live Patching for on-demand instances. These add on products are only available for BYOS, and again this is no change from current policy/behavior.

For those that have applications that need a more stable kABI and that want to run on-demand instances or for those that want to take advantage of the faster integration of Azure features in BYOS instances, keep the above mentioned caveats in mind. The switch between the kernel-default and kernel-azure build is simple.

From kernel-azure to kernel-default (on-demand instances initial switch)
– zypper in –no-recommends kernel-default
– zypper rm kernel-azure
– shutdown -r now

The use of –no-recommends prevents the auto-installation of the kernel-firmware package which is not needed inside a VM.

From kernel-default to kernel-azure (BYOS instances initial switch)
– zypper in –no-recommends kernel-azure
– zypper rm kernel-default
– shutdown -r now

Due to the lifting of the kABI restriction the kernel-azure package is not in SUSE Linux Enterprise Server for SAP Applications images and should not be installed on running instances from those images. It breaks the SAP certification criteria.

With the introduction of the kernel-azure build the image update cadence will change. We will refresh on-demand images on a 3 months rolling schedule. This means that at the latest, 3 months from the previous refresh new images will be available, unless the integration of new features takes longer than expected. Let’s put some dates to this to explain the “at the latest” and “rolling” part. If we assume we refresh images on February 1st and there is no security incident that requires an image refresh. In this case on-demand images with the kernel-azure package built in will be refreshed on May 1st, 3 months after the initial release. But that does not necessarily explain what “rolling” means. Now let’s assume we release an image refresh on May 1st and on June 15th there is a security issue that causes us to refresh our images. That implies that the 3 months clock is reset to 0 on June 15th and the next image refresh would be on September 15 if no other security issue that triggers an image refresh occurs. This is by the way the cadence all other on-demand images will move to later this year.

For those that continue to use SUSE Linux Enterprise Server 12 (SPx) based images, the kernel-azure package will be available in the Update repository starting with SUSE Linux Enterprise Server 12 SP3.

In SUSE Linux Enterprise Server 15, the kernel-azure package is found in the Public Cloud module. The reason for this difference is that in SUSE Linux Enterprise Server 15 the Public Cloud Module is service pack dependent, which allows us to support kernel version upgrades in the module. In SUSE Linux Enterprise Server 12 modules are service pack independent which is a model that does not support kernel version updates. For SUSE Linux Enterprise Server 12 (SPx) users the same zypper process as outlined above works. The SUSE Linux Enterprise Server 12 (SPx) on-demand images will also have the kernel-azure built in the next time we refresh the on-demand images.