We run kernel-ml in production on physical (HP MoonShot, Cisco UCS M)
and virtual machines. Our primary push was for all the updated CIFS
support in kernels > 4.11.
On Wed, Jul 11, 2018 at 5:13 AM Lachlan Musicman <data...@gmail.com> wrote:
>
> While not to the same level of automation and install numbers, we run it on 
> 50-100 serves updating monthly and can report a similar experience and level 
> of satisfaction.
>
> We've had one major issue when Intel fixed it's HMM to behave as advertised 
> but again, a quick google and we were good within acceptable timeframes.
>
> We do have special equipment - the Cisco M Series servers - and the kernel v 
> 3 doesn't have drivers for the LUNs in those - so we used initially out of 
> necessity. But now, as Sam notes, we use because it's more stable and secure.
>
> Cheers
> L.
>
>
> On Wed., 11 Jul. 2018, 19:30 Sam McLeod, <mailingli...@smcleod.net> wrote:
>>
>> Pedro,
>>
>> As Phil says, the kernels are provided 'as-is', but I'd like to give you a 
>> quick sample of how we've found it in production.
>>
>> We run anywhere between 250-2000 CentOS 7 VMs each year.
>> We have been using elrepo kernel-ml on both our VMs and our physical SANs / 
>> storage servers and our physical backup servers for the past 3~ years.
>> We install the latest kernel-ml package as soon as it's available (we 
>> automate everything, the kernel package is ensured that it is the latest 
>> available every 20 minutes~).
>>
>> In those 3~ years we have had (from memory) two problems:
>>
>> 1. Only affected our storage servers, it was some odd kernel bug that caused 
>> some DRBD issues, when we noticed a pattern we just booted into the previous 
>> kernel and the bug was fixed (upstream, in the kernel itself) about 5 
>> releases later (it wasn't very well reported to the kernel devel team or it 
>> would have been quicker, at any rate - nothing to do with elrepo or 
>> kernel-ml).
>>
>> 2. A problem that may have affected intel 7xx series NICs that was again an 
>> upstream kernel bug, saw the problem straight after rebooting into the new 
>> kernel, rebooted into the last kernel - it was fine, left it for a couple of 
>> days until the next build was out - tried it and it was fine.
>>
>> Other than that - kernel-ml has do nothing but provide us with much better 
>> performance and new features (we use a lot of 'newish' things like NVMe, 
>> containers before they were cool, new hardware, self design software defined 
>> storage / SANs etc....).
>>
>> For me and my engineering team it's an absolute no-brainer to use kernel-ml 
>> and there's no way we'd be seen dead running the stock centos 3.x kernels to 
>> be honest.
>>
>> note: we don't use any weird 'black box' oracle / ibm or the likes hardware 
>> that require special kernel drivers to be installed etc... but I haven't 
>> seen people do that much on x86 these days anyway.
>>
>> --
>> Sam McLeod
>> https://smcleod.net
>> https://twitter.com/s_mcleod
>>
>> On 11 Jul 2018, at 08:39, Phil Perry <p...@elrepo.org> wrote:
>>
>> On 10/07/18 18:57, Pedro Flores wrote:
>>
>> We recently started using ELRepo’s kernel repositories in a subset of our 
>> production infrastructure to deal with some issues we were experiencing with 
>> CentOS 7.5 latest kernels.  Our security team has some concerns about how 
>> quickly ElRepo releases new kernel packages that address either major bug 
>> fixes or CVE exploits after the kernels containing these updates have been 
>> released by the Linux Kernel Main archives.    Is there a certain amount of 
>> time that we should expect new kernels to make it to ELREpo yum repositories 
>> after they have been released by the Linux Kernel Archives folks?
>> Thanks in advance.
>> *--*
>> **
>> *Pedro Flores*
>>
>>
>> Hi Pedro,
>>
>> Did you read the release announcement(s)? The relevant part to your question 
>> is here:
>>
>>
>>  These packages are provided "As-Is" with no implied warranty or
>>  support. Using the kernel-lt/-ml may expose your system to security,
>>  performance and/or data corruption issues. Since timely updates may
>>  not be available from the ELRepo Project, the end user has the
>>  ultimate responsibility for deciding whether to continue using the
>>  kernel-ml packages in regular service.
>>
>>
>> Your security team are free to review our previous performance to get an 
>> indication for how quickly kernel packages are typically released, but past 
>> performance should not be taken as a guarantee for future release time 
>> scales.
>>
>> If you have issues with the EL7.5 kernel in a production environment and do 
>> not have the expertise to fix it in house, I would highly recommend you 
>> purchase RHEL subscriptions and raise a support case directly with Red Hat 
>> to have your issues resolved. As stated in our release announcement(s), our 
>> kernel packages are not intended for production use. Elrepo is a voluntary 
>> project and Alan handles all kernel builds single-handedly on donated 
>> limited build hardware. As such, we are unable to offer you any guaranteed 
>> level of service, hence my recommendation to purchase RHEL subscriptions if 
>> that is what you require.
>>
>> Hope that helps,
>>
>> Phil
>>
>> _______________________________________________
>> elrepo mailing list
>> elrepo@lists.elrepo.org
>> http://lists.elrepo.org/mailman/listinfo/elrepo
>>
>>
>> _______________________________________________
>> elrepo mailing list
>> elrepo@lists.elrepo.org
>> http://lists.elrepo.org/mailman/listinfo/elrepo
>
> _______________________________________________
> elrepo mailing list
> elrepo@lists.elrepo.org
> http://lists.elrepo.org/mailman/listinfo/elrepo
_______________________________________________
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo

Reply via email to