ESXi free 8.0 seems to be the last one !
- Thread starter gea
- Start date
Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.
No time like the present?
I should've added: "and will pull"
And one more for fun:
VMware perpetual license holders receive cease-and-desist letters from Broadcom
Broadcom says it may audit VMware users.
arstechnica.com
Yeah, I saw that letter too. I think they did this because of all the dirty rotten scum suckers (all of us) that were still updating their systems, which forced Richard Craniums (Bcom) to implement that token based access. (this is my opinion, yes I consider them "lesser" for their decisions, thus the denigrating moniker)
I had another long email to VMUG this morning, he keeps trying to get me on a phone call to tell me other "stuff", I finally said, "I'm not interested in getting back channel stuff that I'm not allowed to spread to the rest of us", and "just make it known to Bcom that this change will bring piracy, look at Cisco firmwares as an example". (High Brad, yes still salty, you should join the discussion)
I had another long email to VMUG this morning, he keeps trying to get me on a phone call to tell me other "stuff", I finally said, "I'm not interested in getting back channel stuff that I'm not allowed to spread to the rest of us", and "just make it known to Bcom that this change will bring piracy, look at Cisco firmwares as an example". (High Brad, yes still salty, you should join the discussion)
Oh look, a surprised pikachu face from Broadcom regarding a mysterious and utterly unanticipated drop in usage figures and tech community goodwill in 2025 onwards.I should've added: "and will pull"
And one more for fun:
VMware perpetual license holders receive cease-and-desist letters from Broadcom
Broadcom says it may audit VMware users.
According to B-Com, things are moving along exactly as planned. VMware is rapidly becoming the next "mainframe," and only a few graybeards to support it. They will not fix it, it's working as designed. If you are still confused, look up what happened to both CA and Symantec solutions.
Once the short-term money starts to dry out, they will find the next cash cow to butcher.
You can’t blame a snake for biting you; it’s in his nature.
Can you blame bcom for running the Martin shkreli playbook? It’s all they’ve done for many years and everyone knows.
If you want somebody to be mad at blame Michael Dell; he didn’t have to vote yes and if he gave even a single shit about employees or customers he’d have voted no. He knew what would happen and voted yes anyway because money.
Can you blame bcom for running the Martin shkreli playbook? It’s all they’ve done for many years and everyone knows.
If you want somebody to be mad at blame Michael Dell; he didn’t have to vote yes and if he gave even a single shit about employees or customers he’d have voted no. He knew what would happen and voted yes anyway because money.
I thought most of the graybeards at VMware took a severance package and left the company. Product experience from version 7 has been p*iss poor when they started removing drivers present in 6.7. I.e. reduce hardware supported. If your life doesn't depend on it, or you like the bundle Veeam and VMware because it works okay on supported hardware, run, run like Usain Bolt.
As a former VMware employee I will defend VMware’s decision to drop support for vmklinux drivers…it wasn’t VMware that failed to provide drivers that are compatible with v7+; it was the hardware makers who decided not to invest the R&D time to port drivers.
VMware didn’t consciously drop vmklinux driver support to forcibly obsolete old hardware.
VMware didn’t consciously drop vmklinux driver support to forcibly obsolete old hardware.
Would you also mind elaborating, at least in broad strokes, which architecture changes from 6.7 to 7 mandated such drastic changes at first place?
Afaik, the feature improvements in 7 vs 6.7 were abysmally minimal.
When you pay alot of money for the product and 20 years for "maintenance", but that money goes into the CEO's yacht instead of drivers or the vmklinux shim, well guess I am out.
When the CEO blogs that you can run the point release you bought, with security updates until EOL, as long as you want, but months later I find out they have started threatening customers who do so and who let their contracts expire, that's when I say run like Usain Bolt.
Forcing loyal customers into a maze of Indian support hell for DAYS, just to get back access to downloads on this bastard Broadcom support website, killed all remaining goodwill. Licenses 10x in price and bordering ransomware if you don't renew every year, because ESXi hosts will drop off of VCSA and can't even start VMs anymore (officially - let's stick to that), wow.
An argument for OP to keep using it at home and learning about it could have been career opportunities. But with companies migrating off of VMware in droves, a VCP is worth less than toilet paper now. Worth something in Langley, VA or Ft. Meade maybe still, if that is your thing.
Just my own possibly fringe opinion of course, gathered over two decades.
There are far more places that are staying with VMware than you think. Largesse or inertia can be blamed for some. People that bought vxrail from Dell are mostly still happy, Dell is doing the hard work here, and migrated many systems up to 8 a while ago. Self managed and a lot of places are still on 7, support ends in October 2025 for 7.
Mandated? Not sure that could be argued successfully…
But VMware themselves spilled some ink on this exact topic years ago: VMware plans to deprecate vmkLinux APIs and associated driver ecosystem
I understand your frustration and I was impacted by it as well, but I just think you’re mad at the wrong company. VMware didn’t tell the OEMs not to make native drivers for older hardware and OEMs didn’t conspire with VMware to concoct a reason for obsolescence; rather, VMware made a decision for technical reasons and every single OEM independently made a decision for financial reasons. If you want to be mad then be mad at the OEMs…
I can 100% promise you that VMware didn’t arbitrarily make the decision about when to drop support. They have gobs of telemetry data from the field that inform them exactly what hardware customers are running. They made a data-driven decision that ensured the vast majority of customers wouldn’t be impacted. They provided multiple years of advanced notice, too…
As a counterpoint, consider that VMware left Intel Sandy Bridge Xeons on the HCL forever. They could easily have deprecated support for them years before they did and that would have done faaaar more to force upgrades than did the vmklinux driver deprecation…
As another counterpoint, note that VMware dropped support for boot from sdcard because poor flash cell life was causing nightmare problems for customers worldwide and flooding VMware with support tickets (which negatively impacted everyone else’s support experience), but customers objected because they couldn’t realistically go replace boot drives across the install base when most servers were configured with all drive bays already populated for use as datastores—customer servers didn’t have available drive bays to repurpose as boot disks. And VMware rolled back their support policy, instead simply noting that boot from sdcard is strongly not recommended but still supported. VMware had a fabulous technical reason for dropping support and chose not to because customers couldn’t afford to take the hit on functional obsolescence of their server fleets.
So there: that’s two examples of VMware behaving counter to your claims as well as directly answering your question about technical justification for deprecating vmklinux driver support.
I’m not a VMware apologist and I’m certainly not a Broadcom apologist, but in this specific instance I believe people’s feelings are misplaced.
Last edited:
You’re mischaracterizing the cease & desist letters. Broadcom are not telling people they’re not allowed to run perpetual software; they’re telling people that after their support entitlement ends they’re no longer entitled to upgrades.
That was VMware policy for at least the last decade.
Customers habitually abused access to the VMware portal to download updates (ex: vsphere 8.0 U1) they weren’t entitled to because while one part of the organization had dropped support on its licenses another part of the organization had not; since both parts of the organization shared the same license portal the customer admin would grant everyone access to download the latest updates.
VMware turned a blind eye to this abuse for the last decade but they were aware of it and it was explicitly against the terms of service that every customer had signed.
Broadcom is simply choosing not to turn a blind eye to it.
Now all that said that’s not how I would choose to do it. All VMware ever had to do to solve the problem is to make every update require a new license; by making a license key compatible with every point release VMware itself created the pathway for customer abuse.
Broadcom isn’t threatening customers with a lawsuit if they continue to run vsphere 8.0 U3 after they drop support. But they are threatening to sue customers who have licenses with support contracts that expired before U3 was released but are running those licenses on deployments of U3. That’s not a change to their terms of service; it’s just more aggressive enforcement.
I think Broadcom is the devil. I wouldn’t defend them for their wrongdoing. But in this case what they’re doing isn’t wrong and it’s something VMware itself should have done forever ago.
I think vxrail is a steaming pile of malodorous dogshit but I have to give dell credit where due: they did indeed drag a ton of customers forward to modern versions of vsphere.
Thanks, but from your answer and it sounds like you're closer to product or sales teams, rather than an engineering one, since your reply doesn't answer my question, just dances around it.
To address what was NOT said, but was implied in the VMware port you linked to is: Native Driver Model (for short NDM later) is better (shocking), NDM was around 5.5. Again, VMWare, not OEMs decided for business reasons to drop vmkLinux shim, with piss-poor excuse that OEMs couldn't be bothered to re-write drivers for older hardware. Bear in mind - perfect Linux drivers already existed, just native linux drivers ain't good enought for vmware.
To me, this move is 100% counterintuitive since the WHOLE point of virtualization is to obscure the hardware from virtual hardware. Yes, newer hardware => Faster/Better, but dropping support for older (in some cases, only 2-3 years old) hardware goes 100% directly against that idea.
Dropping support for this Linux shim and going only with native NDM drivers likely allowed a much simpler codebase, but at a cost of alienating a significant chunk of customers, forcing more e-waste and unnecessary spending. Again, I restate my point - this was a business and not a technical call. Was it a wrong call for business or not - it's not for me to decide.
Sorry, but both examples aren't that relevant.
A) You could run Windows Server 2022 on Sandy Bridge Xeons, and it's still getting updates
B) SD cards and USB drivers removal - these are purely technical reasons since SD/USB drivers aren't meant to do lots of writes, and pre-v7 ESXI loaded 100% into memory and worked from memory. Sometime around v7, that behavior changed, and ESXi started to do lots of writes onto boot media. This is what caused to drop of that particular design.