Hardware Compatibility Lists (HCL) are an often overlooked, yet they are a very important part of any new deployment that you are attempting. There seems to be an erroneous pervasive notion that the various Hardware Abstraction Layers (HAL) make it so that any hardware can work with anything. However, drivers still must be compatible and the vendor still needs to validate that the hardware you want to use will in fact work with their software. On top of that, there are software compatibility lists, too. It should be of no surprise that not everything supports running on Windows Server 2016 yet, for example. Even to to this day, some applications still can’t run on 64-bit OS, which leaves you stuck with 2008 (an End-of-Life OS) forever.
There are four major potential roadblocks you can hit if you don’t first look at the HCL before you install things:
It just doesn’t work
Sometimes things aren’t qualified because they legitimately just won’t work at all. For example, if you go out and buy a bunch of new servers with 4K drives in them and try to run VMware or vSAN on it, you’re out of luck.
No software support
If you’re not in a supported configuration, you’ll almost certainly not be eligible for support. This leaves a lot of room for your vendor to blame your unsupported configuration for errors and problems, and you won’t receive any assistance or troubleshooting from them.
Questionable software stability
If you’ve ever jumped on a brand-new OS on a brand-new piece of hardware (like, for example, having Dell R710 or HP DL380 G6 trying to run Windows Server 2008 on Nehalem processors right after it all released) you are probably familiar with the fact that a change in hardware can make a piece of software completely unstable. Back then you could run Windows Server 2008 on a X5600 series processor, no problems, rock steady. But install it on the latest greatest Nehalems, and it would bluescreen all the time. This of course, was due to some new power saving features in the new processor architecture that wasn’t yet fully baked into the OS.
Hardware support also goes out the window
If an issue seems like it’s hardware related and you’re running on an unsupported software configuration, it’s somewhat likely your hardware vendor will point the finger at the software. This often means your only option is to downgrade your software or you may not get vendor-provided part replacements. The claim here is that the software doesn’t know how to interact with the hardware and can therefore tell it to do things it isn’t supposed to.
The repercussions of the above issues are pretty severe. Trying to downgrade to other software or replacing the hardware after a purchase is very expensive, either from a man hours perspective or actual hardware purchase standpoint. Depending on the software, it may not even be possible to downgrade, so you may be stuck with your broken or unsupported deployment. It’s also very important to note that vendors don’t qualify every version with every piece of hardware. For example, VMware’s newer versions aren’t supported on older hardware, but older versions of VMware are still supported on that old hardware yet not anything newer.
So how do you go about figuring all this out? Well, every vendor has some kind of support matrix. Generally, you can look for that vendor/product name and HCL on a search engine and you’ll find it.
The VMware HCL page, which I found on Google, is a rather daunting looking thing. However, just change the product to your version of VMware, pick the partner in question (HP, Dell, etc.) and then hit system type (rack mount, tower) and ignore the rest. It will give you a list of qualified products.
VMware’s supported guest OSes matrix has a similar process. Once you’re there, input in the product name, OS family name, ignore the rest, and hit update results.
Or, if you run Windows, the hardware vendors themselves keep the qualified list (a search for “Dell hardware compatibility list Windows,” for example, will do it). Dell’s takes you to this page, which has a link in the second line to a PDF with their compatibility guide.
What’s the moral of the story? An extra 10 minutes of pre-work validating that something will work before you try to implement can save you thousands of dollars or dozens of hours of heartache later.