Grasshopper,
Sorry for the rant, you caught me on a couple of weekend upgrades from 5.1 to 5.5 U1, which was frustrating to say the very least.
the onboard devices not working is not intentional
I’ll have to respectfully disagree, it’s not about getting lucky, whether you’re removing a generic SATA/ACHI/IDE driver in its entirety or just removing PCI IDs from the mapping table of the driver, its a conscious choice so by definition its intentional and the result for the system in question is the same, drives (internal or external) that have been working fine since what, 4.1, disappear.
when it's to stabilize the stack for production I totally agree with that
Agreed, anything that can make any product more stable, I’m in.
running the older versions
Doesn’t running an older version completely defeat the purpose of a development / testing environment? Isn’t the whole idea of a development environment to do your upgrades and testing there first? Wouldn’t I want to know that removing a LUN the way we have been doing for years now kills hosts after a rescan with an “All Paths Down” error in development before I try it in production? Wouldn’t I want to test a new hardware level in development before upgrading production VMs? Wouldn’t I want to know I can no longer manage my hardware level upgraded guests via the vSphere Client in development before we upgrade a remote site and blind ourselves from that location? In a true testing environment running an older version renders the environment by definition completely useless.
just use PCIe add-in cards
Agreed, you can use PCIe cards, but if I need to add 2, 3, 4 cards because of these driver changes, the motherboard most likely doesn’t have the available number of slots let alone the required number of PCI lanes to support it. Not to mention the fact that again, it’s about the capital expenditures required to keep your test environment running after these “upgrades”.
nobody cares more and supports their lab rats more than VMware
Again, sorry, I have to respectfully and strongly disagree on this one. The amount of scripts, workarounds, customizers, etc. that have sprung up over the years so we can continue to use our favorite hypervisor and justify its use to management has past the point of ridiculous, and VM knows this. If this were true there would be VM developed and backed tools, customizers, etc. to aid and encourage the use of non-HCL hardware in order to foster the proliferation of VMWare as a whole instead of crushing it. Any progress in this area does nothing but benefit VMWare in the long run. Any drivers that are added and become stable / proven over time via the user community’s efforts could then be incorporated into the next release thereby expanding VMware’s compatibility, install base, and profits. There is a clear push by VMWare to cripple non-production environments in hopes that people will purchase essentials. Don’t get me wrong, I love the fact that VM created and then reduced the price for essentials (we own a few copies now as well), truly a great move in the right direction to encourage the use of VMWare. But, crippling what ESXi can run on is a complete contradiction to that position. Think about it, we want more people to buy our product so we’ll reduce the initial software licensing expenditures but we’ll force them to buy more expensive hardware? Seriously? From a purely business perspective you’re giving away money to the hardware manufactures that you could be putting in your own pockets. Again, it blows my mind on how out of touch companies can be, this is Business 101 and VMs management team was clearly ditching class that semester.
Possible Solutions
1) Leave all the drivers and PCI Mappings in the distros and if one of those devices is detected put up a big red warning screen during an install or upgrade saying you are about to use drivers that are not on the HCL, but don’t remove them or disable the mappings. Lord knows you warn us all over the place when we enable SSH, warn us when we are running a whitebox clone then too.
2) Remove them from the distro and mappings but add them to the driver rollup, or create a non-HCL rollup. If VM really and truly supports its lab rats then getting ESXi running at all costs on every device possible would be paramount regardless of official compatibility.
3) Microsoft has the BSOD, you have the PSOD, Microsoft has F6 during the install process, why doesn’t VMWare have F3?
4) Release the VMK API Device Driver Development Kit to the community, not just IO Vendor Program members. Again, Business 101, you’ll get drivers converted and tested for free you can then add to your distro which will increase compatibility / usability, which will allow customers to spend less on hardware and more on your licensing, support, and training! Isn't that the underlying goal of any company, get people to spend more money on your product not someone else's (i.e. hardware)? How is it everyone else sees this but VM?
speak your voice and VMware does in fact listen
I think I just did (sorry so long), and I hope they do listen.
keep your head up stick with us
I am trying, but from a purely business perspective it’s becoming harder and harder to justify. What makes it harder is we are planning to expand our datacenter footprint and at the same time some of our current VM support contracts are coming up soon, so everyone’s looking very closely right now.
There are always creative ways to keep using ESXi
Funny, great minds. We’ve been seriously looking into ZFS recently for just that reason but we don’t want to do the “all in one”, so then it’s two servers where there used to be one, and once again I am back to trying to convince management why we need more capital expenditures for development and remote sites.
Again, sorry for the rants, and thank you very much for the reply!
Cheers,
Rockingly