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)?
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.
Thanks!
josh
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:
- 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.
- 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.
- 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.)
- 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
On Oct 30, 2013, at 9:38 AM, Daniel P. Berrange berrange@redhat.com wrote:
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:
- 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.
- 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.
I second Daniel's comments here. In fact, in Icehouse the PCI passthrough support is likely to get better, there is a lot of interest for this especially in the NFV area. NICs are the most likely area of interest here, but I know Intel was also interested in graphics devices and passthrough as well.
Thanks, Kyle
- 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.)
- 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
----- Original Message -----
From: "Josh Boyer" jwboyer@fedoraproject.org To: "Fedora Cloud SIG" cloud@lists.fedoraproject.org Cc: "Kernel Fedora" kernel@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:
- 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.
- 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....)
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?
- 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.)
- Other "cloudy" stuff that I'm entirely unaware of that might be
relevant. Explain it to me like I'm a child.
I have nothing else useful here coming to mind, but I did note this on the PRD just so it's something for us to kep track of - i made a "bucket list" in the detailed requirements section with a link to this mail.
Thanks!
josh _______________________________________________ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On Wed, Oct 30, 2013 at 10:40:44AM -0400, Robyn Bergeron wrote:
----- Original Message -----
From: "Josh Boyer" jwboyer@fedoraproject.org To: "Fedora Cloud SIG" cloud@lists.fedoraproject.org Cc: "Kernel Fedora" kernel@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:
- 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.
- 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.
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.
The two I see on a regular basis is Storage and Network through SRIOV. The other one that is coming up in discussions more and more is GPGPU resources. I know amazon offers this but TBH I'm ignorant as to how they provide this functionality, whether the device is provided by pass-through or whether it's accessed in some other means.
Peter
On Wed, Oct 30, 2013 at 10:07:46AM -0400, Josh Boyer wrote:
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.
I think the main four cases are:
1. Running inside a container 2. Running as a typical guest in a private or public cloud 3. Running as a special guest in the same 4. Running on bare metal (as compute node or possibly host node)
Case 1 is easy -- no kernel, no problem.
Case 2 is everything needed to boot and get network, console output, and normal storage under KVM, Xen (especially as used in EC2), VirtualBox, and VMware. (With priority to the first two.) This *could* be split further, making a distinction between cloud providers, but there's diminishing returns for effort.
Case 3 covers things like PCI passthrough or running a remote desktop where you want virtual sound card support. For this, I think it's perfectly fine to say "add the extra drivers pack".
Case 4 could use a bit more discussion. *Mostly*, I think we can either say that this is the same as case 3 or that we will just use whatever Fedora Server does in this case (if different). However, I know oVirt Node (and probably also OpenStack node) is concerned with image size on bare metal. This would be a good time for anyone interested in that as a focus to chime in.
More responses below....
[...]
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).
Most of that in glibc-common is translations, so that's one of the other things we're working on tackling.
- 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.
Yeah. That also has ripple-effect benefits beyond just the core kernel team (QA, documentation...).
- 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)?
We'll need to develop this in more detail beyond the four general cases above. Possibly one of our first trac tickets. :)
- What are the common provisioning requirements that are driving the
size reduction? (See comment about glibc-common.
Main drivers are network traffic, provisioning speed, and density. With probably a smidgen of marketing thrown in.
I would think change is needed in multiple packages, not just the kernel.)
Yes -- kernel, docs, i18n, python, and then various small changes which add up. Not necessarily in that order -- docs and i18n are actually bigger, and because they apply in the container case, more important.
- Other "cloudy" stuff that I'm entirely unaware of that might be
relevant. Explain it to me like I'm a child.
I hope the above is a good start, and I hope others can chime in what what I've missed.
On Wed, Oct 30, 2013 at 11:04 AM, Matthew Miller mattdm@fedoraproject.org wrote:
On Wed, Oct 30, 2013 at 10:07:46AM -0400, Josh Boyer wrote:
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.
I think the main four cases are:
- Running inside a container
- Running as a typical guest in a private or public cloud
- Running as a special guest in the same
- Running on bare metal (as compute node or possibly host node)
Case 1 is easy -- no kernel, no problem.
Or, perhaps more accurately, that case is covered by either someone else's kernel (which is SEP), or the standard kernel found in Workstation and Server.
Case 2 is everything needed to boot and get network, console output, and normal storage under KVM, Xen (especially as used in EC2), VirtualBox, and VMware. (With priority to the first two.) This *could* be split further, making a distinction between cloud providers, but there's diminishing returns for effort.
I'm going to be blunt. VirtualBox and VMware aren't really focal points for the kernel team, for exact opposite reasons. VirtualBox has open-source userspace but no upstream kernel drivers and has been known to be relatively broken. We just don't support it. VMware has closed userspace, but actually took the time to get their kernel drivers upstream. We build those and we'll care to the point of forwarding bugs in them to the upstream maintainers. However, from a testing point of view we aren't going to have time to make sure the kernel works in those environments. If that is something that is important to the Cloud product, please make sure you invest resources into testing and bug resolution.
Case 3 covers things like PCI passthrough or running a remote desktop where you want virtual sound card support. For this, I think it's perfectly fine to say "add the extra drivers pack".
By which you mean admins manually (or via some tool like puppet/chef/ansible) installs the subpackage, correct? Not "we create a special cloud image with the drier subpackage already included".
Case 4 could use a bit more discussion. *Mostly*, I think we can either say that this is the same as case 3 or that we will just use whatever Fedora Server does in this case (if different). However, I know oVirt Node (and probably also OpenStack node) is concerned with image size on bare metal. This would be a good time for anyone interested in that as a focus to chime in.
OK. I literally have no idea how this is different from a minimal server install, so understanding that would be good.
More responses below....
[...]
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).
Most of that in glibc-common is translations, so that's one of the other things we're working on tackling.
Great. And that package is just a counter-example. As you noted, there are others.
- 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.
Yeah. That also has ripple-effect benefits beyond just the core kernel team (QA, documentation...).
- 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)?
We'll need to develop this in more detail beyond the four general cases above. Possibly one of our first trac tickets. :)
Feel free to CC me. I'm subscribed to the cloud list now, but I can't say I'll have time to fully pay attention to it. Please drag me (or someone else on the kernel team) into specific things if you think you need to.
- What are the common provisioning requirements that are driving the
size reduction? (See comment about glibc-common.
Main drivers are network traffic, provisioning speed, and density. With probably a smidgen of marketing thrown in.
So the thinking is smaller size means less to transfer, faster to boot, cheaper to store? I can see the first one. The second one is mostly either going to be in the noise range or just false. The third one I don't buy.
Now that's all basically image (as in file) size. What about runtime overhead of the kernel? The server group is likely going to want things like NR_CPUS to be larger than it is today, which incurs some runtime memory usage overhead. It isn't huge, but it would be good to know what common provisioning is in the cloud environments you're targeting in terms of memory.
josh
On Thu, Oct 31, 2013 at 11:26:25AM -0400, Josh Boyer wrote:
Case 1 is easy -- no kernel, no problem.
Or, perhaps more accurately, that case is covered by either someone else's kernel (which is SEP), or the standard kernel found in Workstation and Server.
Yes.
Case 2 is everything needed to boot and get network, console output, and normal storage under KVM, Xen (especially as used in EC2), VirtualBox, and VMware. (With priority to the first two.) This *could* be split further, making a distinction between cloud providers, but there's diminishing returns for effort.
I'm going to be blunt. VirtualBox and VMware aren't really focal points for the kernel team, for exact opposite reasons. VirtualBox
Yeah, that's exactly why I put "with priority to the first two". I'm totally happy with making that statement stronger / more clear.
Case 3 covers things like PCI passthrough or running a remote desktop where you want virtual sound card support. For this, I think it's perfectly fine to say "add the extra drivers pack".
By which you mean admins manually (or via some tool like puppet/chef/ansible) installs the subpackage, correct? Not "we create a special cloud image with the drier subpackage already included".
Probably manually, but I think we're still working that out as part of our overall direction.
Case 4 could use a bit more discussion. *Mostly*, I think we can either say that this is the same as case 3 or that we will just use whatever Fedora Server does in this case (if different). However, I know oVirt Node (and probably also OpenStack node) is concerned with image size on bare metal. This would be a good time for anyone interested in that as a focus to chime in.
OK. I literally have no idea how this is different from a minimal server install, so understanding that would be good.
One difference is provisioning via an image vs. anaconada + kickstart.
Feel free to CC me. I'm subscribed to the cloud list now, but I can't say I'll have time to fully pay attention to it. Please drag me (or someone else on the kernel team) into specific things if you think you need to.
Thanks. We will take you up on that.
Main drivers are network traffic, provisioning speed, and density. With probably a smidgen of marketing thrown in.
So the thinking is smaller size means less to transfer, faster to boot, cheaper to store? I can see the first one. The second one is mostly either going to be in the noise range or just false. The third one I don't buy.
Less to transfer is the one that's probably always going to be a meaningful issue, at least in our lifetimes.
Size affects provisioning time because depending on the iaas software, the image is often be completely copied to a new file possibly on a different filesystem. Or on a different machine.
This could be considered a subset of 'network traffic' in some ways, but I'm separating it out because the first includes things like "we don't want to have a Fedora image available by default in $iaasdistro because it's too big to be part of a normal install".
I agree that density is probably the least important because in situations where that's a big concern there are other ways to address it (like deduplication).
Anyone else feel free to chime in if I'm off-base here. :)
Now that's all basically image (as in file) size. What about runtime overhead of the kernel? The server group is likely going to want things like NR_CPUS to be larger than it is today, which incurs some runtime memory usage overhead. It isn't huge, but it would be good to know what common provisioning is in the cloud environments you're targeting in terms of memory.
Good question and I don't have a ready answer. Will keep this in mind as we go through the PRD process.
On Wed, Oct 30, 2013 at 11:04:25AM -0400, Matthew Miller wrote:
Main drivers are network traffic, provisioning speed, and density. With probably a smidgen of marketing thrown in.
I should add that for the "smidgen of marketing", the key target is "not much bigger than the competition, and smaller if possible". Getting much smaller than we are now probably isn't hugely important here, especially in the kernel package. On the other hand, even with the current size as a target, slimming existing packages lets us add more functionality within that same space budget.
On Wed, Oct 30, 2013 at 10:07:46AM -0400, Josh Boyer wrote:
- Other "cloudy" stuff that I'm entirely unaware of that might be
relevant. Explain it to me like I'm a child.
I guess this would be a bad time to mention User-Mode Linux ...? Even I'm not sure if I'm joking here or not, but UML works (surprisingly) and turns out to be more efficient and more reliable than KVM inside a VM (eg. in a cloud instance).
http://libguestfs.org/guestfs.3.html#user-mode-linux-backend
Rich.
Le 30/10/2013 15:07, Josh Boyer a écrit :
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:
- 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.
Seems reasonsable.
- 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)?
We're still discussing our targeted platforms. As for PCI pass-through, if we target hypervisors (KVM, Xen) or virtualization platforms (oVirt, vSphere), it will be a requirement, if we target {I,P}aaS platforms, not so much.
- 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.)
As you pay for storage, the more trimmed down image we can bring, the better. For instance, Ubuntu AWS image is about 228MB compressed and they do pretty well on that matter Uncompressed the raw disk image is 1.5 GB, and the vmlinux 5 MB
4) Other "cloudy" stuff that I'm entirely unaware of that might be relevant. Explain it to me like I'm a child.
Thanks!
josh
Thank you for sharing your concerns with us.
Best regards, H.
Josh, thanks to reaching out to us on this. It's good to know the kernel maintainers are willing to discuss this openly.
On Wed, Oct 30, 2013 at 3:07 PM, Josh Boyer jwboyer@fedoraproject.org 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:
- 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.
- 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)?
- 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.)
- Other "cloudy" stuff that I'm entirely unaware of that might be
relevant. Explain it to me like I'm a child.
So I think it really comes down to two decisions we've yet to make: 1) Which environments (hypervisors both with and without pci-passthrough, containers or bare metal - all three do have valid cloud use cases nowadays) do we want to support and how many different images do we want to create (i.e. one to rule them all or one per environment - or even more granular). The one-to-rule them all will quite certainly require a full Fedora kernel as-is. Well, maybe without stuff that's rather exclusive to workstations but that also goes for the Fedora Server Product, right? The others might leave away some parts (like all real HW in a strictly-for-hypervisors without-pci-passthrough image), depending on how granular we go. 2) Another topic is really that of allowing the user to rebuild our images with slightly(?) different options for a slightly(?) different use case. If we do want to enable users to do that, we might wish to also enable to user to be more granular than we are.
Now, I primarily wonder, how are those 134MB distributed? My filesystem tells me e.g. the net or the media drivers are a large chunk but that doesn't help much. Can't really estimate what parts of that are always necessary, whart are virt HW and what other HW. Anyway, I doubt it makes sense to e.g. remove pcmcia drivers because we don't use them as they are very very small. So I think it would be nice to have: - kernel-virt-hw (all that is found in any of the common hypervisors) - kernel-real-server-hw (any non-virt HW that is not exclusive to workstations) - kernel-real-workstation-hw (any non-virt HW that is exclusive to workstations) - kernel (well, the common / small stuff)
If you're now going to tell me the kernel-virt-hw package would still be rather large, I'd further split that one into smaller sub-packages (e.g. virtio, xen-guest, pci-passthrough, ...)
Not sure if that's possible at all and if so, how useful it is. I don't understand the kernel internals at all, just trying to show you my cloudy dreams. Hopefully, I did not only talk nonsense. :)
-- Sandro
-
Daniel P. Berrange -
Haïkel -
Josh Boyer -
Kyle Mestery (kmestery) -
Matthew Miller -
Peter Robinson -
Richard W.M. Jones -
Robyn Bergeron -
Sandro "red" Mathys