On Wed, Oct 30, 2013 at 10:40:44AM -0400, Robyn Bergeron wrote: > > > ----- Original Message ----- > > From: "Josh Boyer" <jwboyer@xxxxxxxxxxxxxxxxx> > > To: "Fedora Cloud SIG" <cloud@xxxxxxxxxxxxxxxxxxxxxxx> > > Cc: "Kernel Fedora" <kernel@xxxxxxxxxxxxxxxxxxxxxxx> > > 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 :| _______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
