Cloud product kernel requirements

[Daniel P. Berrange]

On Wed, Oct 30, 2013 at 10:40:44AM -0400, Robyn Bergeron wrote:
> 
> 
> ----- Original Message -----
> > From: "Josh Boyer" <jwboyer at fedoraproject.org>
> > To: "Fedora Cloud SIG" <cloud at lists.fedoraproject.org>
> > Cc: "Kernel Fedora" <kernel at lists.fedoraproject.org>
> > Sent: Wednesday, October 30, 2013 7:07:46 AM
> > Subject: Cloud product kernel requirements
> > 
> > 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)?
> 
> I may be totally ... well.. uneducated here, but this sort of sounds a
> bit like it may be related to spice (someone, by all means, tell me if
> i'm just grasping at thin air on this one....)

Well SPICE is providing the link between the guest OS and the client
machine for display interaction purposes. It has the ability to tunnel
access to limited devices, in particular smartcards and USB devices
attached to the client machine.

PCI passthrough though is a different scenario - it is enabling the
guest to use hardware resources present on the physical host. The client
viewer machine isn't involved in this at all. Assigning dedicated virtual
functions to each guest, from a SRIOV NIC on the host is most common
use case for PCI assignment.  VGA passthrough is a less common and more
limited use case, since there aren't any multi-function VGA devices you
can only help 1 single guest per physical host device.

> Anyway - in my googling I saw this mail -
> http://lists.freedesktop.org/archives/spice-devel/2012-November/011353.html
> - i don't know if that is going to help anyone, or not. It's almost making
> me wonder if that's an interesting overlap with the desktop team?

That person has assigned a VGA device from their host to the guest, which
basically takes SPICE out of the equation (from the virt POV), since SPICE
only operates in combination with an emulated VGA device. They have,
however, then run a SPICE server inside the guest for remote access, but
that's outside scope of virt now - just akin to running SPICE on a nonvirt
physical machine.

Regards,
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 :|