Cloud product kernel requirements

[Daniel P. Berrange]

On Wed, Oct 30, 2013 at 10:07:46AM -0400, Josh Boyer wrote:
> Hi All,
> 
> I realize the WG is just forming up and you have a lot of other items
> to cover for now, but I wanted to get this sent out and have people
> start thinking about it sooner rather than later.
> 
> The kernel team has heard in the past that the Cloud group would like
> to see something of a more minimal kernel for usage in cloud images.
> We'd like to hear the requirements for what this smaller image would
> need to cover.
> 
> Right now, a default x86_64 kernel package on f20 is ~134MB installed.
>  Most of that is device drivers installed in /lib/modules/`uname -r`/.
>  The vmlinux binary is about 5MB and the initramfs (which is created
> at install time and can actually vary quite widely depending on
> various things) is about 11MB.  Drivers can be trimmed to a degree,
> but please keep in mind that the kernel is already relatively small
> for the functionality it provides.  For example, it is not much bigger
> than glibc-common (119MB).
> 
> So, some caveats to keep in mind while you're thinking about this:
> 
> 1) We're mostly talking about packaging here, not building a separate
> cloud kernel package or vmlinux.  The kernel team really wants to have
> a single vmlinux across the 3 products if at all possible.  We can't
> scale to much else.
> 
> 2) What usecases is the cloud image going to cover?  E.g. is it just
> virtio stuff, or will it also fit PCI passthru (which then requires
> drivers for those PCI devices)?

FWIW, OpenStack cloud now supports use of PCI passthrough for guests,
so looking at the most general cloud case, we can't remove all the
non-virtio stuff. Most common PCI passthrough usage will likely be
for SRIOV NIC devices, with others more niche use-cases.

> 3) What are the common provisioning requirements that are driving the
> size reduction?  (See comment about glibc-common.  I would think
> change is needed in multiple packages, not just the kernel.)
> 
> 4) Other "cloudy" stuff that I'm entirely unaware of that might be
> relevant.  Explain it to me like I'm a child.

Does anyone have an accurate report on where physical space in the
current cloud image goes to ? Just doing a 'du' on the cloud image
is only giving logical disk space, which doesn't correspond directly
to physical image space, due to differing compression ratios for
different types of content.

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|