On Wed, Dec 30, 2020 at 12:42 PM Lamar Owen <lowen@pari.edu> wrote:
>
> On 12/30/20 3:47 AM, Nico Kadel-Garcia wrote:
> > He should also consider finding a more reputable hardware vendor.
>
> Hey Nico, I'm right here.... :-) Anyway, these servers are Dell. Dell
> isn't a reputable vendor these days?
I've not looked this year. They need careful attention to avoid
changing parts or chipsets without notification and breaking
compatibility with your current, stable kernel. They all do. It was
why, when I did hardware evals, I made sure to get one of any new
model we wanted to order, put it in my test rack, and keep it there
for kernel and OS deployment testing.
> In any case, it's a moot point, since I didn't pick these servers, the
> servers picked me (that is, they were donated to us, and, to modify an
> old saying in my area of the world, "never look a gift server in the
> RAID controller." (the original expression: "never look a gift horse in
> the mouth.")).
If they cost you that much work, consider buying modest Adaptec RAID
controllers. MegaRAID had a bad habit of doing a lot of the RAID work
Adaptec controllers haven't existed as 'distinct' hardware since before 2010. Since then they have been rebranded controllers some of which are MegaRAID, LSI and other systems. For the years between 2010 and 2018, the Megaraid or LSI was a better bet than Adaptec.
in the kernel, not on the attached hardware, which was why the kernel
modules were so critical. And the add-on drivers from the vendor were
usually at least a year behind those in the current Red Hat kernel and
were in fact a regression, as long as we stuck to a contemporary Red
Hat release. RHEL or CentOS these days. I'm very surprised if you have
hardware that actually needs that third-party driver, though it may
take work to get the latest kernel into a bootable ISO or PXE image.
RHEL8 kernels no longer comes with the megaraid controller enabled thus you need the CentOS kernel. The third party module is just the one in the normal kernel compiled.
I have war stories about those drivers.
> > Those so-called "megaraid" chipsets were abominable monstrosities and
> > there were a number of extremely poorly written vendor kernel hacks
> > supporting them.
>
> As mostly an end-user these days, I really couldn't care less what kind
> of hacks are required. I just know that we as a public charity were
> donated these servers to put to use; I intend to put them to use in the
> spirit of the US Internal Revenu Code Section 501(c)(3). They beat the
> two-generations-older Dell PowerEdge 1950s that they are replacing,
> which still use the same basic RAID chipset and have serious performance
> bottlenecks as KVM hosts with modern KVM.
Makes you wonder why someone gave them away?
I believe there was a US Tax benefit for companies if they traded out their hardware after 4 but before 8 years and donated their old hardware to charities. Since there was a lot of hardware being 'donated' most of the US charities only want to take items they can get extended warranties and parts from the manufacturer from.. so getting a donated Dell is better than a donated Supermicro.
Back to CentOS Stream. One of the CentOS kernel advantages was that
Red Hat apparently did test suites across a wide variety of hardware
before considering a kernel for release. I'm afraid CentOS Stream
kernels won't have that regression testing done.
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
https://lists.centos.org/mailman/listinfo/centos-devel