Thanks for the link. I'm probably going to upgrade the mobo so I can go 4.0i, so that will come in handy.

I expected that would happen during version changes (ESX -> ESXi, 3.5i -> 4.0i, etc) but not during a service pack within a version (U2 - > U3). Granted, this is a home machine on an unsupported mobo, but I would be REALLY upset if a device in my production systems became unsupported during an interim/maintenance release. Not good practice on VMware's part, IMHO.

Don't get me wrong, I was definitely (pleasantly) surprised that it worked on that machine.

Mobo's and devices are built around chipsets, and it's not unreasonable to expect that a supported chipset would remain supported through a single major release cycle. If my real servers (or NIC, or storage controller, etc..) had been around one of these chipsets, they would have failed also.

My point is this; When you install a major release, checking the updated HCL is a part of the process. But when you apply a maintenance release, hot fix/patch, service pack, etc. checking the HCL to see if your hardware has been discontinued hardware is not normal procedure. As such, I think discontinuing support for chipsets in the middle of a major version is a dangerous practice.

This is not one of my production systems, and I never said anything about trying to "host multiple simultaneous Guest Server OS's and do it in a very reliable manner". As stated in my first post, this is my home office testbed. A gloried toy if you prefer to think of it that way. Furthermore, the title of the post clearly states that my post is about ESX on whitebox, which implies a non-HCL server. So while I do appreciate the link you provided, your advice is to "get a REAL server" is neither useful, or appreciated.

I didn't bring up backward backwards compatibility because I'm unhappy my little box can't run v4.0. I brought it up because what happened in my case raises the potential of a much bigger problem. While everyone knows that desktops change chipsets almost daily, the specific chipset in this exercise hasn't changed. And since VMware isn't in the habit of developing releases for desktops, it means that at some point a "real" system containing this same chipset (or a close relative thereof) was on the HCL. And since was working in U2, and not working in U3/U4, that means that support for at least one chipset may have been dropped in the middle of a major version. And that is the issue I'm raising. Not which chipsets are supported (or not), but rather that a supported chipset would be dropped in the middle of a major version.