0

There are different Linux kernels for different cloud environments. For example, Canonical offers the linux-azure, linux-kvm, linux-gcp, linux-gke, linux-gkeop, linux-oracle and linux-aws variants, all for the same Ubuntu release, for use with Microsoft Azure cloud, Kernel Virtual Machine KVM, Google Cloud Platform GCP, Google Container Engine GKE, GKE on premises, Oracle systems or Amazon Web Services AWS.

What constitutes the differences between these kernels for different clouds in kernel configuration or applied patches that mandate building different kernels for all of these virtual environments instead of offering just one VM kernel that contains the modules for all the virtual and paravirtualized hardware that these hypervisors are offering and leaving out support for hardware that is missing in any cloud ?

Disclaimer: I'm not asking for the kernels that constitute those cloud platforms and run the hypervisors but I'm asking only for the kernels that are supposed to run inside the VMs.

I'm seeking the big picture that allows an overall understanding of the topic irrespective of all the details of particular cloud environments/hypervisors or different Linux kernel releases or Linux distributions.

Please comment if you downvote such that I can understand the issue.

Improve this question
2
  • If you use platforrms such as GKE/AKS/EKS then you shouldn't care about the kernel. If you using a VM then you decide what kernel you use based on the OS you deploy. What are you actually asking?
    – Stephen Harris
    Commented Jul 6 at 0:38
  • @StephenHarris, I'm asking why there isn't (or can't be) a one-fits-all VM-kernel for all (major) hypervisors.
    – Juergen
    Commented Jul 11 at 0:06

1 Answer 1

Reset to default
1

Quoting "Cloud-optimized Linux kernels – what makes Ubuntu the top OS across the clouds", an Ubuntu blog post by Nikos Mavrogiannopoulos:

  • For AWS:

    [...] Each kernel enables the Elastic Fabric Adapter, allowing high-performance applications to access the network adapter directly for low-latency, reliable transport functionality. Furthermore, linux-aws comes with the Nitro enclaves driver, providing data processing applications a secure enclave with CPU and memory isolation to prevent data leaks. Going beyond x86-64, the arm64 version of the linux-aws kernel brings several patches to take advantage of the unique features of AWS Graviton native CPUs.

  • For GCP:

    Each linux-gcp kernel enables accelerated networking with the Compute Engine Virtual Ethernet device and supports the Google latest Tau VM, enabling scale-out optimized workloads.

  • For Azure:

    Each linux-azure kernel enables accelerated networking for the InfiniBand capable instances, as well as consistent support for the Single Root I/O Virtualization (SR-IOV) on the present hardware, enabling network traffic to bypass the virtualisation stack and achieve almost native performance. It comes with FPGA support out of the box, taking advantage of project catapult to provide performance without the cost and complexity of a custom ASIC.

  • For Oracle:

    Each linux-oracle kernel enables fast networking and boot by taking advantage of the native hardware, while supporting the live migration of Ubuntu guests. Furthermore, the arm64 version of the linux-oracle kernel takes advantage of the unique features of Ampere native CPUs.

Improve this answer
4
  • Which of these features is incompatible to any of the others and thus mandates building an individual VM kernel for just one hypervisor insetead of an universal kernel for all these clouds/hypervisors that contains all of these features ? I suspect the code size can't be the reason as any of these paravirtualized drivers can be modularized and is small anyway.
    – Juergen
    Commented Jul 11 at 0:13
  • I haven't checked, but they may well be patches that haven't been upstreamed yet, so probably haven't been tested to work well (or even work at all) when applied together. After all, there's no incentive for any cloud provider to test another provider's patches for compatibility until the discussion gets into merging work upstream.
    – muru
    Commented Jul 28 at 6:16
  • The kernels in question are not provided (and tested) by the cloud providers but by the Linux distributor (Canonical in my example). So testing the patches all together seems easy and releasing only one universal cloud kernel could make their life easier, if possible. So I suspect there is some incompatibility and thus I asked the question to learn about these suspected incompatibilities.
    – Juergen
    Commented Aug 20 at 9:43
  • I don't know if it makes it any easier for them. I strongly suspect that this isn't just Canonical taking some patches from the providers and trying to integrate them all by themselves, but a collaborative effort with cloud providers' employees also being involved in providing these patches to Canonical and testing them (after all, it's very much in the providers' interests, so I'd expect Canonical to make such a deal with them to reduce the effort on Canonical). If that's the case, they might well think that developing all these separately would be easier.
    – muru
    Commented Aug 20 at 9:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .