On Wed, Oct 28, 2026 at 02:42:47PM +0100, Bastian Blank wrote: j We currently build a separate cloud kernel for amd64 and arm64. It is > meant for usage on specific cloud platforms, AWS, Azure and GCP. This > however does not mean users will not assume it to be usable on all > virtualized platforms. > > Since some time I wonder if it would be useful and possible to > re-designate (and later rename) this kernel for "all" virtualized > platforms. Most of them already work anyway, as they all expose similar > hardware, not the same but similar.
I agree with all of this. > We currently already include: > - Complete non-root support for HyperV. > - Complete non-root support for XEN. > - Support for many of the devices exposed by qemu in both pc and q35 mode. > > What is known to be missing: > - Support for VirtualBox. > > What else? The question is then also: should we then re-add support for > stuff like GFS or so? > > Also in the near future, the second build will go away and we will only > have a stripped down modules package left. So in the future we'll > select by module, not longer by config. How granular do you plan on making the modules packages? Use cases for things like filesystems and network protocols are likely going to be the same across cloud and non-cloud deployments, so it might make sense to have a "common" modules package that's installed by default in just about all cases. The major differences between virtualization platforms is in the device models they expose to guests. Would it be feasible to offer dedicated "aws", "hyperv/azure", "gcp", etc driver packages that provide hardware support for those specific environments? Or is that too much work/overhead? The benefit of such disk space optimizations can be significant when scaled across hundreds or thousands of systems. For the record, I don't love the idea of eliminating the second kernel build. While we haven't taken advantage of this opportunity to this point, it allows us to provide build-time optimizations to best tune performance for specific deployment scenarios. But I suppose runtime tuning is sufficient for most people, as we haven't received any requests for different build-time optimizations afaik. So I don't object too strongly to the plan, and I understand that it offers some advantages. noah
