What happened to kernel-xen?

Those of you in a Xen environment may have noticed a change with recent versions of openSUSE Tumbleweed, or the newly released SUSE Linux Enterprise Server 12 SP2 and openSUSE Leap 42.2. Whether you are looking at a Xen host (dom0), or a paravitual Xen guest (domU), the running kernel is now kernel-default. What happened to kernel-xen?

In earlier releases of SUSE distributions, kernel-xen was a special variant of the kernel which included functionality required to access and run under a Xen hypervisor. The features providing this functionality have now been ported over to the standard, default kernel through the PV-OPS mechanism. This means there is no longer a need for a separate kernel-xen package and binary as everything is provided by the default kernel.

The primary purpose and benefit of this change is to have a single kernel binary to cover all use cases: bare metal, KVM hypervisor, Xen privileged dom0, fully virtual guest (Xen or KVM) and Xen paravirtual guest. This unified kernel approach simplifies maintenance and management, while also ensuring the kernel is more easily and thoroughly tested.

In addition to advantages on the development and testing side, there are some changes and benefits that administrators and users should take note of.

First of all, administrators need to be aware that replacing kernel-xen with kernel-default means that you cannot rely on `uname -r` to determine whether or not you are running under a Xen hypervisor (for example, in a dom0 environment). If you have any scripts or tooling which perform this check, we recommend replacing the uname check with a test for the existence of /proc/xen/privcmd (which only exists in a Xen dom0 environment), or test an xl command, such as `xl info`.

Secondly, the pvops-based frontend block driver (used within SUSE fully virtual, and paravirtual Xen guests) names devices using the ‘xvd*’ syntax. This naming syntax is used even if the backend VM configuration references devices using ‘hd*’ or ‘sd*’ syntax. This should not cause a problem with new VM installations, but when upgrading a VM to a PV-OPS kernel, it may be necessary to manually change the name of the block devices in such places as /etc/fstab or /etc/default/grub. (Guests which reference block devices using UUID or labels will not be impacted by this device naming change.)

Finally, the PV-OPS kernel allows fully virtual machines running this kernel (e.g. Tumbleweed, openSUSE Leap 42.2 and SLES12 SP2) to benefit from PVHVM mode. The details on this mode are quite technical (and misleading statements and descriptions are rather common), but the main benefit of PVHVM is the replacement of emulated interrupts and timers with paravirtual interrupts and timers. This change increases the efficiency of these commonly used events, which could translate to an increase in the efficiency of your VMs.

We are excited about this move to a PV-OPS enabled kernel-default, and look forward to continuing our innovations to help you succeed!

Your SUSE Virtualization Team