[rhelv6-list] RHEL versions, kernel versions, and supportability

[Bryan J Smith]

On Thu, Jul 11, 2013 at 1:27 AM, Kelvin Chu <yskchu at gmail.com> wrote:

> Hi guys,
> Have a question on red hat version and kernel version supportability.
>
> I understand that each minor release comes with an updated kernel; for
> example, 6.2 comes with 2.6.32-220, and 6.3 comes with 2.6.32-279, and 6.4
> comes with 32-358 and 6.0 originally came with 32-71.
>
> Is using a old kernel for a newer release supported?
>
It is _strongly_ recommended that you use the kernel build appropriate for
the user space.

E.g., RHEL 6.4 userspace with 2.6.32-358[.y.z] (which are
6.4) [errata] kernels.

Yes, the RHEL kABI exists so many interfaces are mitigated against change
throughout the entire RHEL lifecycle.  That's so most IHV/ISV software and
even kernel modules can remain unchanged, _if_ they are written to the
kABI, and do not use structures outside of it (more on that in a bit).

However ... with each new Update (aka Point Release), in addition to
Security Errata (RHSA) and limited Bugfix Errata (RHBA) that are normally
released mid-Update (same Point Release), there are more Bugfix Errata
(RHBA) and Enhancement Errata (RHEA) for the new Update (new Point
Release).  These additional changes -- especially Enhancements which are
always by and for Customers -- may require newer and/or different userspace
to support.

So ... coming back to IHV/ISVs who go "outside" the kABI ... is that why
you're looking to stick with an old kernel on a new Update userspace?

E.g., RHEL 6.4 userspace with 2.6.32-279[.y.z] (6.3 series) [errata] kernel
because your IHV or ISV requires the 6.3 kernel series for their modules?

If so ... you should get Extended Update Support (EUS) entitlement(s) for
your system(s). [1]

EUS started out, and is also known as, the "Z-stream," where errata kernels
(and select other packages, as required) are maintained for an older Update
(Point Release) after a newer Update comes out.  E.g., RHEL 6.3 EUS would
continue to have newer 2.6.32-279.y.z kernels, even after 6.4 was released
and 2.6.32-358[.y.z] builds now the "HEAD" tag.  This Z-stream mitigates
changes to select Security fixes and only required Bugfix errata to
mitigate any changes to the kernel and its structures.

So ... EUS and its Z-stream mitigates problems with IHVs and ISVs that go
outside the Red Hat kABI and modify other structures and interfaces.  All
the while EUS releases are still maintained as if the old Update was still
the "HEAD" tag.  It gives your IHV and ISV 18-24+ months to migrate to a
newer Update, much longer than the typical Update cycle of 6-9 months.  In
fact, some IHV and ISVs virtually _never_ seem to even release during the
"HEAD" update, so EUS is absolutely required to deal with such situations.

See the RHEL Lifecycle document for more information on typical release
cycles, including EUS dates for RHEL6. [2]

EUS is very advantageous in Enterprises, and I've worked in several where
policy _required_ all RHEL systems to be subscribed to the EUS channels
unless there was an exception, or the solution itself always required the
"HEAD" Update (latest Point Release).  EUS and access to the Z-streams are
a very minimal charge beyond a RHEL entitlement, and I highly recommend it
to improve management and other aspects of your enterprise if you are
finding you are deploying older Updates.  Again, if you have troubling IHV
and ISV solutions that require older Updates that are not receiving
security updates like the "HEAD" Update, you really should get your
enterprise on EUS.

Every single enterprise, and even some smaller shops, I've been at that
went EUS have never wanted to go back, and cannot believe they didn't know
about it before.  ;)

-- bjs

P.S.  If you do _not_ have EUS, you _should_ be on the latest Update
(latest Point Release), kernel and userspace.  E.g., everyone without an
EUS subscription should be on RHEL 6.4 (or RHEL 5.9 in the case of RHEL5 --
ignoring ELS for RHEL3/4, which is different than EUS).  If not, then
issues may arise and/or you may accidentally "re-cover ground" with Red Hat
GSS that has already been addressed in the new Update, and would have
solved your issue.  I've seen this several times myself, hence why this is
my strong, professional recommendation.  YMMV.

[1] Extended Update Support
 -
http://www.redhat.com/products/enterprise-linux-add-ons/extended-update-support/

[2] Red Hat Enterprise Linux Life Cycle
 - https://access.redhat.com/support/policy/updates/errata/

"In Red Hat Enterprise Linux 6, EUS is available for the following minor
releases:
 - 6.0 (ends November 30, 2012)
 - 6.1 (ends May 31, 2013)
 - 6.2 (ends December 31, 2013)
 - 6.3 (ends June 30, 2014)
 - 6.4 (ends February 28, 2015)"


--
Bryan J Smith - Professional, Technical Annoyance
b.j.smith at ieee.org - http://www.linkedin.com/in/bjsmith
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/rhelv6-list/attachments/20130711/bf4caf81/attachment.htm>