On Wed, Mar 5, 2014 at 9:59 AM, Gerd Hoffmann kraxel@redhat.com wrote:
Hi,
I'm not overly thrilled with having multi-tiered driver packages. That leads to major headaches when we start shuffling things around from one driver package to another. The current solution I have prototyped is a kernel-core/kernel-drivers split. Here "core" could be analogous to "cloud", but I imagine it will be useful for other things. People wanting to do PCI passthrough can just install the kernel-drivers package.
Agree, I don't think it makes much sense to split things into many small pieces.
- Do you need/want a firewall (requires iptables, etc)?
I'd say yes by default, but being able to remove it might be useful (kernel-netfilter subpackage)?
So you agree multi-tiered subpackages is a bad idea, but then you propose a netfilter specific subpackage? ... Probably not. They'll likely just be in kernel-core.
- Do you need/want NFS or other cloudy storage things (for gluster?)?
I'm personally using NFS for host/guest filesystem sharing, so I'd vote yes.
- Do you need/want openvswitch?
I think no. That's a host side thing and this is about the guest kernel, right?
Nested virt? I dunno, it was mentioned at one point so I thought I'd bring it up for discussion again.
The list of modules I have in my local rawhide KVM guest is below. The snd_* related drivers probably aren't necessary. The btrfs and things it depends on can be ignored (unless you plan on switching from ext4).
Depends on what is targeted. Strictly cloud? Or also someone running Fedora as a guest in virt-manager / boxes?
I'm of the opinion the latter is probably what we should shoot for. It's going to be the broadest target that is still reasonably small.
I'd tend to include drivers for pretty much everything qemu can emulate.
uinput 17708 1
spice guest agent uses this.
bluetooth 445507 5 bnep cfg80211 583354 0
bluetooth+wireless are not needed, dunno why they are loaded.
Me either. I'm guessing because systemd/NetworkManager on my KVM guest auto-loads them.
snd_hda_codec_generic 66943 1 snd_hda_intel 56588 4
For the qemu HDA soundcard. Should be included if desktop usecase should be covered too.
qxl 74078 2
gpu driver. There are also cirrus + bochs-drm for qemu. vmware vga has a drm driver too. They should be included.
ata_generic 12910 0 pata_acpi 13038 0
IDE. Needed. Qemu can emulate AHCI too, should be included (but I think that is =y anyway).
Qemu can emulate a bunch of SCSI HBAs. Don't think we need the drivers for them (except virtio-scsi). vmware emulates SCSI HBAs too. pvscsi should be included. Dunno about the older ones, there was for example some buslogic emulation in older vmware workstation versions ...
USB: Qemu can also emulate uhci + ehci + xhci, should be included. Also usb-storage and generic hid support (for the usb tablet). IIRC most of this is =y anyway.
NIC: e1000, rtl8139 (qemu), tulip (hyperv), dunno about vmware. qemu can also emulate a bunch of other nics such as ne2k, but I think those are not relevant in practice and not needed.
Of course all paravirtual drivers should be included too, i.e.
- all virtio (for qemu)
- all xen frontend (for xen, the backend drivers are for the host side and are not needed in the guest).
- all hyperv (for hyperv)
OK. Was planning on that already.
josh
On Wed, Mar 05, 2014 at 10:08:04 -0500, Josh Boyer jwboyer@fedoraproject.org wrote:
So you agree multi-tiered subpackages is a bad idea, but then you propose a netfilter specific subpackage? ... Probably not. They'll likely just be in kernel-core.
Couldn't the planned module provides allow something like this to work without worry much about which modules are in which packages? netfilter could juts require the modules it needs and it would pull in and extra kernel module packages that are needed.
On Wed, Mar 5, 2014 at 10:51 AM, Bruno Wolff III bruno@wolff.to wrote:
On Wed, Mar 05, 2014 at 10:08:04 -0500, Josh Boyer jwboyer@fedoraproject.org wrote:
So you agree multi-tiered subpackages is a bad idea, but then you propose a netfilter specific subpackage? ... Probably not. They'll likely just be in kernel-core.
Couldn't the planned module provides allow something like this to work without worry much about which modules are in which packages? netfilter could juts require the modules it needs and it would pull in and extra kernel module packages that are needed.
Possibly. But it's not just the installed system to be taken into account. Every additional subpackage and list is something that needs to be maintained and further complicates the kernel.spec file. It adds to testing all the combinations of kernel packages and subpackages being installed (or not) and upgraded, etc. For the sake of the kernel maintainers, keeping it limited is probably a good idea.
And honestly, a firewall in today's world seems pretty darn "core" to me anyway.
josh
On Wed, Mar 05, 2014 at 10:08:04AM -0500, Josh Boyer wrote:
Depends on what is targeted. Strictly cloud? Or also someone running Fedora as a guest in virt-manager / boxes?
I'm of the opinion the latter is probably what we should shoot for. It's going to be the broadest target that is still reasonably small.
I agree that this is valuable, because it lets the same image be used for testing locally.
On Thu, Mar 6, 2014 at 12:08 AM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Wed, Mar 5, 2014 at 9:59 AM, Gerd Hoffmann kraxel@redhat.com wrote:
Hi,
I'm not overly thrilled with having multi-tiered driver packages. That leads to major headaches when we start shuffling things around from one driver package to another. The current solution I have prototyped is a kernel-core/kernel-drivers split. Here "core" could be analogous to "cloud", but I imagine it will be useful for other things. People wanting to do PCI passthrough can just install the kernel-drivers package.
Fair enough, agreed. We might need to eventually revisit this decision if SRIOV or graphic cards computing really take off and people complain. But right now, it's edge cases.
Agree, I don't think it makes much sense to split things into many small pieces.
- Do you need/want a firewall (requires iptables, etc)?
While not strictly necessary (the IaaS usually puts a firewall right in front of the instance / guest), I think we do want to allow each and everyone to optimize their security needs. The local iptables also has way more capabilities than the provided one offers.
I'd say yes by default, but being able to remove it might be useful (kernel-netfilter subpackage)?
So you agree multi-tiered subpackages is a bad idea, but then you propose a netfilter specific subpackage? ... Probably not. They'll likely just be in kernel-core.
- Do you need/want NFS or other cloudy storage things (for gluster?)?
Usually, you just attach additional volumes when you need more space but, particularly in private clouds, people do all kinds of weird things to get their data from here to there so I think we want all storage options. Also, support for every (major) filesystem that you could put on additionally attached disk drives.
I'm personally using NFS for host/guest filesystem sharing, so I'd vote yes.
- Do you need/want openvswitch?
I think no. That's a host side thing and this is about the guest kernel, right?
Nested virt? I dunno, it was mentioned at one point so I thought I'd bring it up for discussion again.
There are use cases that use OVS but I'd say they are rare. And nested virt is even rarer (particularly since Docker helped pushing lxc). So I don't think we want OVS in the guest image.
The list of modules I have in my local rawhide KVM guest is below. The snd_* related drivers probably aren't necessary. The btrfs and things it depends on can be ignored (unless you plan on switching from ext4).
As mentioned above, btrfs could be used on user-attached drives so keep that in there. But the root disk will be in line with the other Fedora products.
Depends on what is targeted. Strictly cloud? Or also someone running Fedora as a guest in virt-manager / boxes?
I'm of the opinion the latter is probably what we should shoot for. It's going to be the broadest target that is still reasonably small.
"Guest in virt-manager" is not part of our PRD, so it's not actually required. But as Matt mentioned, it's incredibly valuable for testing purposes. That should be a good enough reason to include something reasonably small.
I'd tend to include drivers for pretty much everything qemu can emulate.
<snip-snap detailed module talk>
OK. Was planning on that already.
Make it so :)
-- Sandro